From 635ed09579b61597fadcb7b20c1e1bf6324a3af6 Mon Sep 17 00:00:00 2001 From: Diogo <112647953+dsm-w3f@users.noreply.github.com> Date: Tue, 8 Nov 2022 11:37:08 -0300 Subject: [PATCH 001/959] Update accepted_grant_applications.md to check Ventur first delivery (#1265) --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index a6dc4e26a0b..91a55ac4dcc 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -536,7 +536,7 @@ | [Redstone Network](https://github.com/difttt) | Redstone Network | [GitHub](https://github.com/difttt) | | | | | [JURIMETRIC TECNOLOGIA LTDA](https://www.jurimetric.com.br/) | Polkadart | [GitHub](https://github.com/rankanizer/polkadart) | | | | | [Skye Kiwi](https://skye.kiwi/) | Choko Wallet | [GitHub](https://github.com/skyekiwi) | | | | -| [Popular Coding](https://www.popularcoding.com/) | Ventur | [GitHub](https://github.com/popular_coding) | | | | +| [Popular Coding](https://www.popularcoding.com/) | Ventur | [GitHub](https://github.com/popular_coding) | | | | | [Asylum](https://asylum.space/) | Asylum follow-up 1 | [GitHub](https://gitlab.com/asylum-space/) | | | | | [Cyril Carlier](https://github.com/CrommVardek) | Maki| [GitHub](https://github.com/CrommVardek) | | | | | [TopMonks](https://www.topmonks.com/) | Calamar| [GitHub](https://github.com/topmonks/calamar) | | | | From f0c4241a537e0fccbdac8db78dd47eadf7b3a779 Mon Sep 17 00:00:00 2001 From: Aleixo Sanchez <15819210+alxs@users.noreply.github.com> Date: Wed, 9 Nov 2022 08:57:47 +0100 Subject: [PATCH 002/959] Encourage no token mentions + generic project description (#1263) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * No token mentions + generic project description * Update README.md Co-authored-by: Sebastian Müller Co-authored-by: David Hawig Co-authored-by: Sebastian Müller --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index b02bc807e62..8dba583e05b 100644 --- a/README.md +++ b/README.md @@ -47,6 +47,7 @@ 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. - 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. - 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. From 726f7ffb55f849169f7d4bc5bafd8f014a20836c Mon Sep 17 00:00:00 2001 From: Xavier Lau Date: Wed, 9 Nov 2022 21:05:58 +0800 Subject: [PATCH 003/959] Amend Subalfred milestone deliverables (#1267) Signed-off-by: Xavier Lau Signed-off-by: Xavier Lau --- applications/subalfred.md | 51 ++++++++++++++++++++------------------- 1 file changed, 26 insertions(+), 25 deletions(-) diff --git a/applications/subalfred.md b/applications/subalfred.md index edf6bea89e7..7a92df55d8a 100644 --- a/applications/subalfred.md +++ b/applications/subalfred.md @@ -92,36 +92,34 @@ There are three parts: - **FTE:** 1 - **Costs:** 24,000 USD -| Number | Deliverable | Specification | -| -----: | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -| 0a. | License | GPLv3 | -| 0b. | Documentation | I'll document every `pub` function and a basic tutorial that explains how a user interact with Subalfred. | -| 0c. | Testing guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests. | -| 0d. | Docker | I'll provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 1. | Core: check features | I'll finish the this features, which is use for checking Substrate runtime runtime-benchmarks/std/try-runtime features enable status. | -| 2. | Core: use paritytech/ss58-registry | I'll make PR to paritytech/ss58-registry to support my custom logic, and setup the dependabot to update ss58-registry automatically. | -| 3. | Core, CLI: override runtime code | I'll make it able to override the runtime code while fork-off the chain state. | -| 3. | Core, CLI: rpc | I'll finish the this features, user could use this command to send the RPC call to the Substrate node. | -| 4. | CLI: JSON output | I'll make `key` command provides JSON output. | -| 5. | CLI: stable Rust toolchain | I'll rewrite the subcommand parts in procedure macro to remove the unstable Rust features usage. | -| 6. | CLI: `--at` accept block number | I'll make the `--at` arg accept block number input, instead of a block hash only. Any command with `--at` arg will be updated. | -| 7. | Releases | Linux, macOS, Windows prebuilt binaries, and crates.io release. | +| Number | Deliverable | Specification | +| -----: | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | +| 0a. | License | GPLv3 | +| 0b. | Documentation | I'll document every `pub` function and a basic tutorial that explains how a user interact with Subalfred. | +| 0c. | Testing guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. Simply run `cargo test` under the project root. | +| 1. | Core: check features | I'll finish the this features, which is use for checking Substrate runtime runtime-benchmarks/std/try-runtime features enable status. | +| 2. | Core: use paritytech/ss58-registry | I'll make PR to paritytech/ss58-registry to support my custom logic, and setup the dependabot to update ss58-registry automatically. | +| 3. | Core, CLI: override runtime code | I'll make it able to override the runtime code while fork-off the chain state. | +| 3. | Core, CLI: rpc | I'll finish the this features, user could use this command to send the RPC call to the Substrate node. | +| 4. | CLI: JSON output | I'll make `key` command provides JSON output. |a +| 5. | CLI: stable Rust toolchain | I'll rewrite the subcommand parts in procedure macro to remove the unstable Rust features usage. | +| 6. | CLI: `--at` accept block number | I'll make the `--at` arg accept block number input, instead of a block hash only. Any command with `--at` arg will be updated. | +| 7. | Releases | Linux, macOS, Windows prebuilt binaries, and crates.io release. | ### Milestone 2 — Add more new features - **Estimated Duration:** 2 week - **FTE:** 1 - **Costs:** 4000 USD -| Number | Deliverable | Specification | -| -----: | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | -| 0a. | License | GPLv3 | -| 0b. | Documentation | I'll document every `pub` function and a basic tutorial that explains how a user interact with Subalfred. | -| 0c. | Testing guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests. | -| 0d. | Docker | I'll provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 1. | License | GPLv3. | -| 2. | Core, CLI: track-updates | List the companions that you need to do from substrate/cumulus/frontier/parity-bridges-substrate. | -| 3. | Core, CLI: update-subdeps | Update the substrate/cumulus/frontier/parity-bridges-substrate dependencies in one command. | -| 4. | Releases | Release Linux, macOS, Windows prebuilt binaries on GitHub, and crates.io. | +| Number | Deliverable | Specification | +| -----: | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | +| 0a. | License | GPLv3 | +| 0b. | Documentation | I'll document every `pub` function and a basic tutorial that explains how a user interact with Subalfred. | +| 0c. | Testing guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. Simply run `cargo test` under the project root. | +| 1. | License | GPLv3. | +| 2. | Core, CLI: track-updates | List the companions that you need to do from substrate/cumulus/frontier/parity-bridges-substrate. | +| 3. | Core, CLI: update-subdeps | Update the substrate/cumulus/frontier/parity-bridges-substrate dependencies in one command. | +| 4. | Releases | Release Linux, macOS, Windows prebuilt binaries on GitHub, and crates.io. | ### Milestone 3 — Provide checks' GitHub Actions - **Estimated Duration:** 1 week @@ -132,7 +130,7 @@ There are three parts: | -----: | -------------------------------------- | ---------------------------------------------------------------------------------------------- | | 0a. | License | GPLv3 | | 0b. | Documentation | I'll provide the inline documentation. | -| 0c. | Testing guide | I'll provide a GitHub Actions setup example and describe how to check the result. | +| 0c. | Testing guide | I'll provide a GitHub Actions setup example and describe how to check the result. | | 1. | GitHub Actions: check runtime features | I'll provide a GitHub Actions, which could check the runtime features status while developing. | | 2. | GitHub Actions: check runtime storage | I'll provide a GitHub Actions, which could check the runtime storage changes while developing. | | 3. | GitHub Actions: check runtime version | I'll provide a GitHub Actions, which could check the runtime version changes while developing. | @@ -158,3 +156,6 @@ Please note this is a part of milestone 1. I'd love to convert these milestone to issues on the [repository](https://github.com/hack-ink/subalfred). It will be much easier to track the status. + +### Amending +- Remove **0.d** from milestone **1** and **2**. Because I realize that it is much easier for you to test this with a simple `cargo test` command. So, I decide to use **cargo** instead of **docker**. [Discussion](https://github.com/w3f/Grant-Milestone-Delivery/pull/615#issuecomment-1308480639) From 3216bb3de9e1f3c652e029b94d864d60faec18c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20M=C3=BCller?= Date: Fri, 11 Nov 2022 08:44:13 +0000 Subject: [PATCH 004/959] Replace emojis in accepted_grant_applications.md for docusaurus (#1269) * Update accepted_grant_applications.md * Replace checkmarks with html * update with box without a cross * fix code link Co-authored-by: Noc2 --- docs/accepted_grant_applications.md | 990 ++++++++++++++-------------- 1 file changed, 495 insertions(+), 495 deletions(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 91a55ac4dcc..a5747aa5b94 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -11,562 +11,562 @@ ## Table of Contents - [2019](#2019) - - [:surfing_woman: Wave 1 - First Quarter 2019](#surfing_woman-wave-1---first-quarter-2019) - - [:surfing_woman: Wave 2 - Second Quarter 2019](#surfing_woman-wave-2---second-quarter-2019) - - [:surfing_woman: Wave 3 - Third Quarter 2019](#surfing_woman-wave-3---third-quarter-2019) - - [:surfing_woman: Wave 4 - Fourth Quarter 2019](#surfing_woman-wave-4---fourth-quarter-2019) + - [🏄‍♀️ Wave 1 - First Quarter 2019](#surfing_woman-wave-1---first-quarter-2019) + - [🏄‍♀️ Wave 2 - Second Quarter 2019](#surfing_woman-wave-2---second-quarter-2019) + - [🏄‍♀️ Wave 3 - Third Quarter 2019](#surfing_woman-wave-3---third-quarter-2019) + - [🏄‍♀️ Wave 4 - Fourth Quarter 2019](#surfing_woman-wave-4---fourth-quarter-2019) - [2020](#2020) - - [:surfing_woman: Wave 5 - First Quarter 2020](#surfing_woman-wave-5---first-quarter-2020) - - [:surfing_woman: Wave 6 - Second Quarter 2020](#surfing_woman-wave-6---second-quarter-2020) - - [:surfing_woman: Wave 7 - Third Quarter 2020](#surfing_woman-wave-7---third-quarter-2020) - - [:surfing_woman: Wave 8 - Fourth Quarter 2020](#surfing_woman-wave-8---fourth-quarter-2020) + - [🏄‍♀️ Wave 5 - First Quarter 2020](#surfing_woman-wave-5---first-quarter-2020) + - [🏄‍♀️ Wave 6 - Second Quarter 2020](#surfing_woman-wave-6---second-quarter-2020) + - [🏄‍♀️ Wave 7 - Third Quarter 2020](#surfing_woman-wave-7---third-quarter-2020) + - [🏄‍♀️ Wave 8 - Fourth Quarter 2020](#surfing_woman-wave-8---fourth-quarter-2020) - [2021](#2021) - - [:surfing_woman: Wave 9 - First Quarter 2021](#surfing_woman-wave-9---first-quarter-2021) - - [:surfing_woman: Wave 10 - Second Quarter 2021](#surfing_woman-wave-10---second-quarter-2021) - - [:surfing_woman: Wave 11 - Third Quarter 2021](#surfing_woman-wave-11---third-quarter-2021) - - [:surfing_woman: Wave 12 - Fourth Quarter 2021](#surfing_woman-wave-12---fourth-quarter-2021) + - [🏄‍♀️ Wave 9 - First Quarter 2021](#surfing_woman-wave-9---first-quarter-2021) + - [🏄‍♀️ Wave 10 - Second Quarter 2021](#surfing_woman-wave-10---second-quarter-2021) + - [🏄‍♀️ Wave 11 - Third Quarter 2021](#surfing_woman-wave-11---third-quarter-2021) + - [🏄‍♀️ Wave 12 - Fourth Quarter 2021](#surfing_woman-wave-12---fourth-quarter-2021) - [2022](#2022) - - [:surfing_woman: Wave 13 - First Quarter 2022](#surfing_woman-wave-13---first-quarter-2022) - - [:surfing_woman: Wave 14 - Second Quarter 2022](#surfing_woman-wave-14---second-quarter-2022) - - [:surfing_woman: Wave 15 - Third Quarter 2022](#surfing_woman-wave-15---third-quarter-2022) - - [:surfing_woman: Wave 16 - Fourth Quarter 2022](#surfing_woman-wave-16---fourth-quarter-2022) + - [🏄‍♀️ Wave 13 - First Quarter 2022](#surfing_woman-wave-13---first-quarter-2022) + - [🏄‍♀️ Wave 14 - Second Quarter 2022](#surfing_woman-wave-14---second-quarter-2022) + - [🏄‍♀️ Wave 15 - Third Quarter 2022](#surfing_woman-wave-15---third-quarter-2022) + - [🏄‍♀️ Wave 16 - Fourth Quarter 2022](#surfing_woman-wave-16---fourth-quarter-2022) # 2019 -## :surfing_woman: Wave 1 - First Quarter 2019 +## 🏄‍♀️ Wave 1 - First Quarter 2019 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [ChainSafe](https://chainsafe.io/) | Polkadot Runtime Environment in Go (via an RFP) | [GitHub](https://github.com/ChainSafeSystems/gossamer) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Soramitsu](https://soramitsu.co.jp/) | Polkadot Runtime Environment in C++ (via an RFP) | [GitHub](https://github.com/soramitsu/kagome) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [WEB3SCAN](https://www.web3scan.com/) | Polkascan: Open Source Block Explorer | [GitHub](https://github.com/polkascan) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Polkawallet](https://polkawallet.io/) | Mobile Wallet | [GitHub](https://github.com/polkawallet-io/polkawallet-RN) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Validators](http://validators.com/) | Open Source Scalable Cluster | [GitHub](https://github.com/Validators) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [BlockX Labs](http://blockxlabs.com/) | Enzyme Browser extension wallet | [GitHub](https://github.com/blockxlabs/enzyme) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Speckle OS](https://www.speckleos.io/) | Browser extension wallet | [GitHub](https://github.com/SpeckleOS/speckle-browser-extension) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Noise Explorer](https://symbolic.software/) | Rust code generator for formally verified (Noise/ cryptographic) handshakes | [Source Code](https://source.symbolic.software/noiseexplorer/noiseexplorer) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Protos](http://protosmanagement.com/) | Open Source Node Explorer | [GitHub](https://github.com/protos-research/polkadot-node-explorer) |
  • [x]
|
  • [x]
|
  • [ ]
| -| [Supercomputing Systems](https://www.scs.ch/) | Substrate Transaction Privacy using Intel SGX | [GitHub](https://github.com/scs/substraTEE) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 2 - Second Quarter 2019 +| [ChainSafe](https://chainsafe.io/) | Polkadot Runtime Environment in Go (via an RFP) | [GitHub](https://github.com/ChainSafeSystems/gossamer) | ☐ | ☒ | ☒ | +| [Soramitsu](https://soramitsu.co.jp/) | Polkadot Runtime Environment in C++ (via an RFP) | [GitHub](https://github.com/soramitsu/kagome) | ☐ | ☒ | ☒ | +| [WEB3SCAN](https://www.web3scan.com/) | Polkascan: Open Source Block Explorer | [GitHub](https://github.com/polkascan) | ☐ | ☒ | ☒ | +| [Polkawallet](https://polkawallet.io/) | Mobile Wallet | [GitHub](https://github.com/polkawallet-io/polkawallet-RN) | ☐ | ☒ | ☐ | +| [Validators](http://validators.com/) | Open Source Scalable Cluster | [GitHub](https://github.com/Validators) | ☐ | ☒ | ☒ | +| [BlockX Labs](http://blockxlabs.com/) | Enzyme Browser extension wallet | [GitHub](https://github.com/blockxlabs/enzyme) | ☐ | ☒ | ☒ | +| [Speckle OS](https://www.speckleos.io/) | Browser extension wallet | [GitHub](https://github.com/SpeckleOS/speckle-browser-extension) | ☐ | ☒ | ☒ | +| [Noise Explorer](https://symbolic.software/) | Rust code generator for formally verified (Noise/ cryptographic) handshakes | [Source Code](https://source.symbolic.software/noiseexplorer/noiseexplorer) | ☐ | ☒ | ☒ | +| [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 | [GitHub](https://github.com/scs/substraTEE) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 2 - Second Quarter 2019 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Cap9](https://cap9.io/) | A low-level security protocol and framework for smart contracts | [GitHub](https://github.com/Daohub-io/cap9) |
  • [ ]
|
  • [x]
|
  • [x]
| -| Substrate Java API | Java version of our JS API | [GitHub](https://github.com/polkadot-java) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Starlog](https://pact.care/) | A metadata chain for IPFS | [GitHub](https://github.com/PACTCare/Starlog) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [MixBytes](https://mixbytes.io/) | Benchmarking tool for Substrate and Polkadot | [GitHub](https://github.com/mixbytes/tank) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Gunclear](https://gunclear.io/) | Private secure data storage solution using Plasma Cash in Substrate | [GitHub](https://github.com/GunClear) |
  • [x]
|
  • [x]
|
  • [ ]
| -| [ZeroChain](https://layerx.co.jp/) | Zero knowledge transactions in Substrate | [GitHub](https://github.com/LayerXcom/zero-chain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Robonomics](https://robonomics.network/) | Substrate modules for controlling robots | [GitHub](https://github.com/airalab/substrate-node-robonomics) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Avado](https://ava.do/) | Polkadot node deployment with consumer hardware | [GitHub](https://github.com/AvadoDServer/AVADO-DNP-Polkadot-custom) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stake Technologies](https://stake.co.jp/) | Plasma modules for Substrate | [GitHub](https://github.com/staketechnologies/Plasm) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [HOPR](https://hopr.network/) | Substrate integration with this P2P messaging protocol | [GitHub](https://github.com/validitylabs/HOPR-PL-Substrate) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Mailchain](https://mailchain.xyz/) | a Multi-Blockchain Messaging Application | [GitHub](https://github.com/mailchain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Usetech](http://usetech.com/blockchain.html) | Polkadot C++ API | [GitHub](https://github.com/usetech-llc/polkadot_api_cpp) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 3 - Third Quarter 2019 +| [Cap9](https://cap9.io/) | A low-level security protocol and framework for smart contracts | [GitHub](https://github.com/Daohub-io/cap9) | ☐ | ☒ | ☒ | +| Substrate Java API | Java version of our JS API | [GitHub](https://github.com/polkadot-java) | ☐ | ☒ | ☒ | +| [Starlog](https://pact.care/) | A metadata chain for IPFS | [GitHub](https://github.com/PACTCare/Starlog) | ☐ | ☒ | ☐ | +| [MixBytes](https://mixbytes.io/) | Benchmarking tool for Substrate and Polkadot | [GitHub](https://github.com/mixbytes/tank) | ☐ | ☒ | ☒ | +| [Gunclear](https://gunclear.io/) | Private secure data storage solution using Plasma Cash in Substrate | [GitHub](https://github.com/GunClear) | ☒ | ☒ | ☐ | +| [ZeroChain](https://layerx.co.jp/) | Zero knowledge transactions in Substrate | [GitHub](https://github.com/LayerXcom/zero-chain) | ☐ | ☒ | ☒ | +| [Robonomics](https://robonomics.network/) | Substrate modules for controlling robots | [GitHub](https://github.com/airalab/substrate-node-robonomics) | ☐ | ☒ | ☐ | +| [Avado](https://ava.do/) | Polkadot node deployment with consumer hardware | [GitHub](https://github.com/AvadoDServer/AVADO-DNP-Polkadot-custom) | ☐ | ☒ | ☒ | +| [Stake Technologies](https://stake.co.jp/) | Plasma modules for Substrate | [GitHub](https://github.com/staketechnologies/Plasm) | ☐ | ☒ | ☒ | +| [HOPR](https://hopr.network/) | Substrate integration with this P2P messaging protocol | [GitHub](https://github.com/validitylabs/HOPR-PL-Substrate) | ☐ | ☒ | ☒ | +| [Mailchain](https://mailchain.xyz/) | a Multi-Blockchain Messaging Application | [GitHub](https://github.com/mailchain) | ☐ | ☒ | ☒ | +| [Usetech](http://usetech.com/blockchain.html) | Polkadot C++ API | [GitHub](https://github.com/usetech-llc/polkadot_api_cpp) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 3 - Third Quarter 2019 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Supercomputing systems](http://scs.ch/) | Substrate Rust API client | [GitHub](https://github.com/scs/substrate-api-client) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [NGRAVE](https://ngrave.io/) | Substrate Hardware Wallet Integration | |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Caelum Labs](https://caelumlabs.com/) | Decentralised identity modules | |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Runtime Verification](https://runtimeverification.com/) | Build executable K specifications of the SRML | [GitHub](https://github.com/runtimeverification/polkadot-verification) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Attic Lab](https://atticlab.net/) | VS Code and Atom plugins | [GitHub](https://github.com/everstake/VSCode-Atom-Plugin) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Dock](http://dock.io/) | Verifiable Claims | |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Blockdaemon](https://blockdaemon.com/) | Polkadot Package Manager | [GitHub](https://github.com/Blockdaemon/bpm-sdk) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zondax](http://zondax.ch/) | Ledger app for Polkadot | [GitHub](https://github.com/ZondaX/ledger-polkadot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Geefu](https://www.geefu.net/) | Vue JS components for Polkadot JS apps | [GitHub](https://github.com/vue-polkadot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Centrifuge](https://centrifuge.io/) | Substrate Go API client | [GitHub](http://github.com/centrifuge) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Litentry](https://www.litentry.com/) | Identity modules and corresponding UIs | [GitHub](https://github.com/litentry/litentry-runtime) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [DappForce](http://dappforce.io) | SubSocial - Substrate module and web UI for decentralized communities | [GitHub](https://github.com/dappforce/dappforce-subsocial) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Phala.Network](https://phala.network/) | pLibra, Privacy Bridge between Polkadot and Libra chain | [GitHub](https://github.com/Phala-Network/) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Wiv](http://wiv.io/) | Supply chain modules and front-end UI | [GitHub](https://github.com/wivtech) |
  • [x]
|
  • [ ]
|
  • [ ]
| - -## :surfing_woman: Wave 4 - Fourth Quarter 2019 +| [Supercomputing systems](http://scs.ch/) | Substrate Rust API client | [GitHub](https://github.com/scs/substrate-api-client) | ☐ | ☒ | ☒ | +| [NGRAVE](https://ngrave.io/) | Substrate Hardware Wallet Integration | N/A | ☐ | ☒ | ☐ | +| [Caelum Labs](https://caelumlabs.com/) | Decentralised identity modules | | ☐ | ☒ | ☐ | +| [Runtime Verification](https://runtimeverification.com/) | Build executable K specifications of the SRML | [GitHub](https://github.com/runtimeverification/polkadot-verification) | ☐ | ☒ | ☒ | +| [Attic Lab](https://atticlab.net/) | VS Code and Atom plugins | [GitHub](https://github.com/everstake/VSCode-Atom-Plugin) | ☐ | ☒ | ☒ | +| [Dock](http://dock.io/) | Verifiable Claims | | ☐ | ☒ | ☐ | +| [Blockdaemon](https://blockdaemon.com/) | Polkadot Package Manager | [GitHub](https://github.com/Blockdaemon/bpm-sdk) | ☐ | ☒ | ☒ | +| [Zondax](http://zondax.ch/) | Ledger app for Polkadot | [GitHub](https://github.com/ZondaX/ledger-polkadot) | ☐ | ☒ | ☒ | +| [Geefu](https://www.geefu.net/) | Vue JS components for Polkadot JS apps | [GitHub](https://github.com/vue-polkadot) | ☐ | ☒ | ☒ | +| [Centrifuge](https://centrifuge.io/) | Substrate Go API client | [GitHub](http://github.com/centrifuge) | ☐ | ☒ | ☒ | +| [Litentry](https://www.litentry.com/) | Identity modules and corresponding UIs | [GitHub](https://github.com/litentry/litentry-runtime) | ☐ | ☒ | ☒ | +| [DappForce](http://dappforce.io) | SubSocial - Substrate module and web UI for decentralized communities | [GitHub](https://github.com/dappforce/dappforce-subsocial) | ☐ | ☒ | ☒ | +| [Phala.Network](https://phala.network/) | pLibra, Privacy Bridge between Polkadot and Libra chain | [GitHub](https://github.com/Phala-Network/) | ☐ | ☒ | ☐ | +| [Wiv](http://wiv.io/) | Supply chain modules and front-end UI | [GitHub](https://github.com/wivtech) | ☒ | ☐ | ☐ | + +## 🏄‍♀️ Wave 4 - Fourth Quarter 2019 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Genesis Lab](https://genesislab.net/) | Validator Tracker | [GitHub](https://github.com/genesis-lab-team) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Usetech](http://usetech.com/blockchain.html) | Substrate API in .NET | [GitHub](https://github.com/usetech-llc/polkadot_api_dotnet) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [BlockX Labs](http://blockxlabs.com/) | Enzyme Browser extension wallet | [GitHub](https://github.com/blockxlabs/enzyme) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [WEB3SCAN](https://www.web3scan.com/) | Python API client | [GitHub](https://github.com/polkascan) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Galactic Council](https://github.com/galacticcouncil) | Polkalert: Validator Monitoring | [GitHub](https://github.com/galacticcouncil/polkalert) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Bandot](http://bandot.io/) | Stablecoin | [GitHub](https://github.com/bandotorg/Bandot) |
  • [x]
|
  • [x]
|
  • [ ]
| -| [Laminar One](https://laminar.one/) | LaminarChain: High performance Flow Protocols powering synthetic asset and margin trading | [GitHub](https://github.com/laminar-protocol/laminar-chain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stake Technologies](https://stake.co.jp/) | Ink! Playground | [GitHub](https://github.com/staketechnologies/ink-playground) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [B-Harvest](https://bharvest.io/) | Node Monitoring Tool | [GitHub](https://github.com/b-harvest) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Simply VC](https://simply-vc.com.mt/) | P.A.N.I.C. Validator alerting solution | [GitHub](https://github.com/SimplyVC/panic_polkadot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Ethworks](https://ethworks.io/) | Polkadot{.js} extension improvements | [GitHub](https://github.com/ethWorks) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Lyken Software Solutions](https://lyken.rs/) | Investigation of runtime compilation | [GitHub](https://github.com/LykenSol) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Blockchain IT](blockchain-it.hr) | Ink! Remix Plugin | [GitHub](https://github.com/blockchain-it-hr/ink-remix-plugin) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Kadena](https://www.kadena.io/) | Pact feasibility study | [GitHub](https://github.com/kadena-io/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [STAFI Protocol](http://www.stafi.io/) | Stafi is a protocol to provide liquidity for staking assets | [GitHub](https://github.com/stafiprotocol/stafi-node) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Vision Baker](https://playproject.io/) | DatDot — Dat protocol for Polkadot | [GitHub](https://github.com/playproject-io/datdot) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Speckle OS](https://www.speckleos.io/) | Integrating additional features into Speckle OS | [GitHub](https://github.com/SpeckleOS/speckle-browser-extension) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Archipel](https://archipel.id/) | Solution to resolve high availability problem of Validator nodes in PoS | [GitHub](https://github.com/luguslabs/archipel) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zondax](https://zondax.ch/) | Flexible TrustZone-based HSM stack | [GitHub](https://github.com/ZondaX) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Usetech](http://usetech.com/blockchain.html) | SR25519 library in pure C and C# | [GitHub](https://github.com/usetech-llc/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Akropolis](https://akropolis.io/) | PolkaHub — Heroku-like infrastructure for node deployment | [GitHub](https://github.com/akropolisio) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Pixura](https://pixura.io/) | Substrate API client in Haskell | [GitHub](https://github.com/Pixura) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [HashQuark](https://www.hashquark.io/) | Validator Dashboard | [GitHub](https://github.com/hashquark-io) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stacktical](https://stacktical.com/) | Performance Management Runtime Modules | [GitHub](https://github.com/Stacktical) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Sean Young](https://www.mess.org/) | Solidity to WASM compiler | [GitHub](https://github.com/hyperledger-labs/solang) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Chain Security](https://chainsecurity.com/) | Tool for validating correctness of Polkadot runtimes | [GitHub](https://github.com/ChainSecurity) |
  • [ ]
|
  • [x]
|
  • [x]
| +| [Genesis Lab](https://genesislab.net/) | Validator Tracker | [GitHub](https://github.com/genesis-lab-team) | ☐ | ☒ | ☒ | +| [Usetech](http://usetech.com/blockchain.html) | Substrate API in .NET | [GitHub](https://github.com/usetech-llc/polkadot_api_dotnet) | ☐ | ☒ | ☒ | +| [BlockX Labs](http://blockxlabs.com/) | Enzyme Browser extension wallet | [GitHub](https://github.com/blockxlabs/enzyme) | ☐ | ☒ | ☒ | +| [WEB3SCAN](https://www.web3scan.com/) | Python API client | [GitHub](https://github.com/polkascan) | ☐ | ☒ | ☒ | +| [Galactic Council](https://github.com/galacticcouncil) | Polkalert: Validator Monitoring | [GitHub](https://github.com/galacticcouncil/polkalert) | ☐ | ☒ | ☒ | +| [Bandot](http://bandot.io/) | Stablecoin | [GitHub](https://github.com/bandotorg/Bandot) | ☒ | ☒ | ☐ | +| [Laminar One](https://laminar.one/) | LaminarChain: High performance Flow Protocols powering synthetic asset and margin trading | [GitHub](https://github.com/laminar-protocol/laminar-chain) | ☐ | ☒ | ☒ | +| [Stake Technologies](https://stake.co.jp/) | Ink! Playground | [GitHub](https://github.com/staketechnologies/ink-playground) | ☐ | ☒ | ☒ | +| [B-Harvest](https://bharvest.io/) | Node Monitoring Tool | [GitHub](https://github.com/b-harvest) | ☐ | ☒ | ☐ | +| [Simply VC](https://simply-vc.com.mt/) | P.A.N.I.C. Validator alerting solution | [GitHub](https://github.com/SimplyVC/panic_polkadot) | ☐ | ☒ | ☒ | +| [Ethworks](https://ethworks.io/) | Polkadot{.js} extension improvements | [GitHub](https://github.com/ethWorks) | ☐ | ☒ | ☒ | +| [Lyken Software Solutions](https://lyken.rs/) | Investigation of runtime compilation | [GitHub](https://github.com/LykenSol) | ☐ | ☒ | ☒ | +| [Blockchain IT](blockchain-it.hr) | Ink! Remix Plugin | [GitHub](https://github.com/blockchain-it-hr/ink-remix-plugin) | ☐ | ☒ | ☒ | +| [Kadena](https://www.kadena.io/) | Pact feasibility study | [GitHub](https://github.com/kadena-io/) | ☐ | ☐ | ☐ | +| [STAFI Protocol](http://www.stafi.io/) | Stafi is a protocol to provide liquidity for staking assets | [GitHub](https://github.com/stafiprotocol/stafi-node) | ☐ | ☒ | ☒ | +| [Vision Baker](https://playproject.io/) | DatDot — Dat protocol for Polkadot | [GitHub](https://github.com/playproject-io/datdot) | ☐ | ☒ | ☐ | +| [Speckle OS](https://www.speckleos.io/) | Integrating additional features into Speckle OS | [GitHub](https://github.com/SpeckleOS/speckle-browser-extension) | ☐ | ☐ | ☐ | +| [Archipel](https://archipel.id/) | Solution to resolve high availability problem of Validator nodes in PoS | [GitHub](https://github.com/luguslabs/archipel) | ☐ | ☒ | ☒ | +| [Zondax](https://zondax.ch/) | Flexible TrustZone-based HSM stack | [GitHub](https://github.com/ZondaX) | ☐ | ☒ | ☒ | +| [Usetech](http://usetech.com/blockchain.html) | SR25519 library in pure C and C# | [GitHub](https://github.com/usetech-llc/) | ☐ | ☒ | ☒ | +| [Akropolis](https://akropolis.io/) | PolkaHub — Heroku-like infrastructure for node deployment | [GitHub](https://github.com/akropolisio) | ☐ | ☒ | ☒ | +| [Pixura](https://pixura.io/) | Substrate API client in Haskell | [GitHub](https://github.com/Pixura) | ☐ | ☐ | ☐ | +| [HashQuark](https://www.hashquark.io/) | Validator Dashboard | [GitHub](https://github.com/hashquark-io) | ☐ | ☒ | ☒ | +| [Stacktical](https://stacktical.com/) | Performance Management Runtime Modules | [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) | ☐ | ☒ | ☒ | # 2020 -## :surfing_woman: Wave 5 - First Quarter 2020 +## 🏄‍♀️ Wave 5 - First Quarter 2020 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Bifrost](https://bifrost.finance/) | EOS interoperable bridge | [GitHub](https://github.com/bifrost-finance) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Entropy Labs](https://entropylabs.hk) | A toolkit for building and deploying applications with substrate | |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Papers GmbH](https://airgap.it) | AirGap - Desktop (+mobile) wallet for Polkadot | [GitHub](https://github.com/airgap-it) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stake Technologies](https://stake.co.jp/) | Plasm Chain + OVM Implementation | [GitHub](https://github.com/staketechnologies/) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Usetech](http://usetech.com/blockchain.html) | PostgreSQL Indexer and Consensus Insurer | [GitHub](https://github.com/usetech-llc/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Acala](https://acala.network/) | A decentralized stablecoin platform | [GitHub](https://github.com/AcalaNetwork) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ETCDEV](https://emeraldpay.io/) | Polkadot Network Crawler | [GitHub](https://github.com/emeraldpay) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Xaya](https://xaya.io/) | Decentralised Complex Gaming | [GitHub](https://github.com/xaya) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Celer](https://www.celer.network/) | Layer 2 Scaling Infrastructure | [GitHub](https://github.com/celer-network) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Cryptoeconomics Lab](https://www.cryptoeconomicslab.com/) | Substrate adapter of Plasma child chain | [GitHub](https://github.com/cryptoeconomicslab) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Centrifuge / ChainSafe](https://centrifuge.io/) | Substrate / Ethereum Bridge | [GitHub 1](https://github.com/centrifuge/), [Github 2](https://github.com/ChainSafe/ChainBridge) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Advanca](https://www.advanca.network/) | Privacy-preserving general-purpose compute/storage layer | [GitHub](https://github.com/advanca) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Nodle](https://nodle.io) | Securely identify, certify and verify IoT devices | [GitHub](http://github.com/NodleCode/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Figment](https://figment.network/) | DotHub: Information Hub for validators and delegators | [GitHub](https://github.com/figment-networks/dothub) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Lunie](http://lunie.io/) | Web and mobile wallet | [GitHub](https://github.com/luniehq/lunie) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Web3 Gardens](https://web3.garden) | Runtime modules and UI for creating stable, well-governed communities on Substrate | [GitHub](https://github.com/web3garden/sunshine) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Itering](https://itering.com/) | Ruby Substrate API | [GitHub](https://github.com/itering) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [WEB3SCAN](https://www.web3scan.com/) | Identity Pallet for Polkascan | [GitHub](https://github.com/polkascan) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Swisscom Blockchain AG](https://www.blockchain.swisscom.com/) | Kubernetes Operator for Sentry nodes or Validators deployment | [GitHub](https://github.com/swisscom-blockchain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Polkastats](https://polkastats.io/) | Polkadot/Kusama network statistics | [GitHub](https://github.com/Colm3na/polkastats-v3) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Supercomputing Systems](https://www.scs.ch/) | SubstraTEE extension pack | [GitHub](https://github.com/scs/substraTEE) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Encointer](https://encointer.org/) | An Ecological, Egalitarian and Private Cryptocurrency and Self-Sovereign Identity System | [GitHub](https://github.com/encointer) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [FlexDapps](https://flexdapps.com/) | Gantree is a full-service node infrastructure toolkit for Substrate-based blockchains | [GitHub](https://github.com/flex-dapps) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Matter Labs](https://matter-labs.io) | Zinc/RedShift ZK programming framework | [GitHub](https://github.com/matter-labs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Second State](https://www.secondstate.io/) | Bridging Ethereum Tools and Smart Contracts into Substrate Ecosystem | [GitHub](https://github.com/second-state) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Sensio.Group](https://ipfs.io/ipfs/bafybeihoqt3gvmd5wbqkxt52lojuvbvgoydan3aadxhvf37qdyvpgl762e/index.html) | Substrate modules + UI that focus on photo copyright and privacy | [GitLab](https://gitlab.com/sensio_group) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [KILT](https://kilt.io/) | Substrate Anonymous Credentials | [GitHub](https://github.com/KILTprotocol) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Node Factory](https://www.nodefactory.io/) | Metamask plugin for Polkadot | [GitHub](https://github.com/nodefactoryIo) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Interlay](https://www.interlay.io/) | Polkadot/BTC bridge specification (RFP) | [GitLab](https://gitlab.com/interlay/polkabtc-spec) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stake Technologies](https://stake.co.jp/) | ECDSA for Polkadot JS | [GitHub](https://github.com/staketechnologies/apps) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Obsidian Labs](https://www.obsidians.io/) | Substrate IDE | [GitHub](https://github.com/ObsidianLabs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Definex](https://definex.io/) | A financial market protocol | [GitHub](https://github.com/definex/definex-libs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Attic Lab](https://atticlab.net/) | Multisignature Wallet Standardization/PSP | [GitHub](https://github.com/w3f/PSPs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ImToken](https://token.im/) | Multi-chain non-custodial mobile and hardware wallet for iOS & Android | [GitHub](https://github.com/consenlabs/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SelfKey](https://selfkey.org/) | SelfKey DIDs & Claims as Ink! Smart Contracts | [GitHub](https://github.com/SelfKeyFoundation) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Lyken](https://lyken.rs/) | Rust trait system revamp | [GitHub](https://github.com/LykenSol) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Chorus One](https://chorus.one/) | Grandpa light client in Tendermint | [GitHub](https://github.com/ChorusOne) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 6 - Second Quarter 2020 +| [Bifrost](https://bifrost.finance/) | EOS interoperable bridge | [GitHub](https://github.com/bifrost-finance) | ☐ | ☒ | ☒ | +| [Entropy Labs](https://entropylabs.hk) | A toolkit for building and deploying applications with substrate | | ☐ | ☒ | ☐ | +| [Papers GmbH](https://airgap.it) | AirGap - Desktop (+mobile) wallet for Polkadot | [GitHub](https://github.com/airgap-it) | ☐ | ☒ | ☒ | +| [Stake Technologies](https://stake.co.jp/) | Plasm Chain + OVM Implementation | [GitHub](https://github.com/staketechnologies/) | ☐ | ☒ | ☐ | +| [Usetech](http://usetech.com/blockchain.html) | PostgreSQL Indexer and Consensus Insurer | [GitHub](https://github.com/usetech-llc/) | ☐ | ☒ | ☒ | +| [Acala](https://acala.network/) | A decentralized stablecoin platform | [GitHub](https://github.com/AcalaNetwork) | ☐ | ☒ | ☒ | +| [ETCDEV](https://emeraldpay.io/) | Polkadot Network Crawler | [GitHub](https://github.com/emeraldpay) | ☐ | ☒ | ☒ | +| [Xaya](https://xaya.io/) | Decentralised Complex Gaming | [GitHub](https://github.com/xaya) | ☐ | ☒ | ☒ | +| [Celer](https://www.celer.network/) | Layer 2 Scaling Infrastructure | [GitHub](https://github.com/celer-network) | ☐ | ☒ | ☐ | +| [Cryptoeconomics Lab](https://www.cryptoeconomicslab.com/) | Substrate adapter of Plasma child chain | [GitHub](https://github.com/cryptoeconomicslab) | ☐ | ☐ | ☐ | +| [Centrifuge / ChainSafe](https://centrifuge.io/) | Substrate / Ethereum Bridge | [GitHub 1](https://github.com/centrifuge/), [Github 2](https://github.com/ChainSafe/ChainBridge) | ☐ | ☒ | ☒ | +| [Advanca](https://www.advanca.network/) | Privacy-preserving general-purpose compute/storage layer | [GitHub](https://github.com/advanca) | ☐ | ☒ | ☒ | +| [Nodle](https://nodle.io) | Securely identify, certify and verify IoT devices | [GitHub](http://github.com/NodleCode/) | ☐ | ☒ | ☒ | +| [Figment](https://figment.network/) | DotHub: Information Hub for validators and delegators | [GitHub](https://github.com/figment-networks/dothub) | ☐ | ☒ | ☒ | +| [Lunie](http://lunie.io/) | Web and mobile wallet | [GitHub](https://github.com/luniehq/lunie) | ☐ | ☒ | ☒ | +| [Web3 Gardens](https://web3.garden) | Runtime modules and UI for creating stable, well-governed communities on Substrate | [GitHub](https://github.com/web3garden/sunshine) | ☐ | ☒ | ☐ | +| [Itering](https://itering.com/) | Ruby Substrate API | [GitHub](https://github.com/itering) | ☐ | ☒ | ☒ | +| [WEB3SCAN](https://www.web3scan.com/) | Identity Pallet for Polkascan | [GitHub](https://github.com/polkascan) | ☐ | ☒ | ☒ | +| [Swisscom Blockchain AG](https://www.blockchain.swisscom.com/) | Kubernetes Operator for Sentry nodes or Validators deployment | [GitHub](https://github.com/swisscom-blockchain) | ☐ | ☒ | ☒ | +| [Polkastats](https://polkastats.io/) | Polkadot/Kusama network statistics | [GitHub](https://github.com/Colm3na/polkastats-v3) | ☐ | ☒ | ☒ | +| [Supercomputing Systems](https://www.scs.ch/) | SubstraTEE extension pack | [GitHub](https://github.com/scs/substraTEE) | ☐ | ☒ | ☒ | +| [Encointer](https://encointer.org/) | An Ecological, Egalitarian and Private Cryptocurrency and Self-Sovereign Identity System | [GitHub](https://github.com/encointer) | ☐ | ☒ | ☒ | +| [FlexDapps](https://flexdapps.com/) | Gantree is a full-service node infrastructure toolkit for Substrate-based blockchains | [GitHub](https://github.com/flex-dapps) | ☐ | ☒ | ☒ | +| [Matter Labs](https://matter-labs.io) | Zinc/RedShift ZK programming framework | [GitHub](https://github.com/matter-labs) | ☐ | ☐ | ☐ | +| [Second State](https://www.secondstate.io/) | Bridging Ethereum Tools and Smart Contracts into Substrate Ecosystem | [GitHub](https://github.com/second-state) | ☐ | ☒ | ☒ | +| [Sensio.Group](https://ipfs.io/ipfs/bafybeihoqt3gvmd5wbqkxt52lojuvbvgoydan3aadxhvf37qdyvpgl762e/index.html) | Substrate modules + UI that focus on photo copyright and privacy | [GitLab](https://gitlab.com/sensio_group) | ☐ | ☒ | ☐ | +| [KILT](https://kilt.io/) | Substrate Anonymous Credentials | [GitHub](https://github.com/KILTprotocol) | ☐ | ☒ | ☒ | +| [Node Factory](https://www.nodefactory.io/) | Metamask plugin for Polkadot | [GitHub](https://github.com/nodefactoryIo) | ☐ | ☒ | ☒ | +| [Interlay](https://www.interlay.io/) | Polkadot/BTC bridge specification (RFP) | [GitLab](https://gitlab.com/interlay/polkabtc-spec) | ☐ | ☒ | ☒ | +| [Stake Technologies](https://stake.co.jp/) | ECDSA for Polkadot JS | [GitHub](https://github.com/staketechnologies/apps) | ☐ | ☒ | ☒ | +| [Obsidian Labs](https://www.obsidians.io/) | Substrate IDE | [GitHub](https://github.com/ObsidianLabs) | ☐ | ☒ | ☒ | +| [Definex](https://definex.io/) | A financial market protocol | [GitHub](https://github.com/definex/definex-libs) | ☐ | ☒ | ☒ | +| [Attic Lab](https://atticlab.net/) | Multisignature Wallet Standardization/PSP | [GitHub](https://github.com/w3f/PSPs) | ☐ | ☒ | ☒ | +| [ImToken](https://token.im/) | Multi-chain non-custodial mobile and hardware wallet for iOS & Android | [GitHub](https://github.com/consenlabs/) | ☐ | ☒ | ☒ | +| [SelfKey](https://selfkey.org/) | SelfKey DIDs & Claims as Ink! Smart Contracts | [GitHub](https://github.com/SelfKeyFoundation) | ☐ | ☐ | ☐ | +| [Lyken](https://lyken.rs/) | Rust trait system revamp | [GitHub](https://github.com/LykenSol) | ☐ | ☒ | ☐ | +| [Chorus One](https://chorus.one/) | Grandpa light client in Tendermint | [GitHub](https://github.com/ChorusOne) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 6 - Second Quarter 2020 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Protofire](https://protofire.io/) | Failover mechanism for validators | [GitHub](https://github.com/protofire) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [HashQuark](https://www.hashquark.io/) | Validator Dashboard Phase 2 | [GitHub](https://github.com/hashquark-io) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [BUIDL Labs](https://buidllabs.io/) | YieldScan Staking Dashboard | [GitHub](https://github.com/buidl-labs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| BoBao Technologies | PolkaKey an electron app to generate Polkadot addresses + tutorials | [GitHub](https://github.com/w3finance/PolkaKey) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Webassembly Security](https://webassembly-security.com/) | Improving security and resilience of WebAssembly runtimes | [GitHub](https://github.com/pventuzelo/wasm_runtimes_fuzzing) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Finoa](https://finoa.io/) | C library for Substrate | [GitHub](https://github.com/finoabanking/substrate-c-tool) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Crust Network](https://crust.network/) | Incentive layer protocol for decentralized storage | [GitHub](https://github.com/crustio) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ETCDEV](https://emeraldpay.io/) | Polkadot Java Client | [GitHub](https://github.com/emeraldpay) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zondax](http://zondax.ch/) | Ledger app for Polkadot/Kusama Phase 2 | [GitHub](https://github.com/ZondaX/ledger-polkadot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Soramitsu](https://soramitsu.co.jp/) | Hyperledger Iroha Bridge | [GitHub](https://github.com/sora-xor/polkaswap-web) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [LimeChain](https://github.com/LimeChain) | AssemblyScript SCALE Codec | [GitHub](https://github.com/LimeChain/as-scale-codec) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Insight](https://insightfellows.com/) | Load Balanced Endpoints | [GitHub](https://github.com/insight-w3f/terragrunt-polkadot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Ethworks](https://ethworks.io/) | Polkadot.{js} Desktop Application | [GitHub](https://github.com/EthWorks/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Usetech](http://usetech.com/blockchain.html) | NFT Tracking Module | [GitHub](https://github.com/usetech-llc/nft_parachain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Chevdor](https://www.chevdor.com/) | Polkabot | [GitHub](https://github.com/chevdor) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Aleksandr Krupenkin](https://github.com/akru) | Haskell Web3 library | [GitHub](https://github.com/airalab/hs-web3) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [WEB3SCAN](https://www.web3scan.com/) | Polkascan Signer Interfaces | [GitHub](https://github.com/polkascan) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Fortmatic](https://fortmatic.com/) | SDK + Burner Wallet to implement Web 2.0 login for dapps | [GitHub](https://github.com/fortmatic) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [PureStake](https://www.purestake.com/) | Web3 Compatible API | [GitHub](https://github.com/PureStake) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Phala.Network](https://phala.network/) | Web3 Analytics | [GitHub](https://github.com/Phala-Network/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [TerenceGe](https://github.com/TerenceGe) | C implementation of Schnorrkel | [GitHub](https://github.com/TerenceGe/sr25519-donna) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Adoriasoft](https://adoriasoft.com/) | Cosmos-SDK Parachain Development Kit | [GitHub](https://github.com/adoriasoft/cosmos-sdk) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Laminar One](https://laminar.one/) | Reusable Libraries: Runtime Modules + Monitoring Framework | [GitHub](https://github.com/open-web3-stack) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Faber](https://github.com/yxf) | Subwallet: CLI wallet for Polkadot/Substrate | [GitHub](https://github.com/yxf/subwallet) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Equilibrium.co](https://equilibrium.co/) | offchain::ipfs | [GitHub](https://github.com/eqlabs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Snowfork](http://www.snowfork.com/) | Ethereum Bridge | [GitHub](https://github.com/snowfork) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Lunie](http://lunie.io/) | Lunie Governance integration | [GitHub](https://github.com/luniehq/lunie) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [LimeChain](https://github.com/LimeChain) | AssemblyScript Runtime | [GitHub](https://github.com/LimeChain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [MVP Workshop](https://mvpworkshop.co/) | Substrate startkit GUI (marketplace for substrate pallets) | [GitHub](https://github.com/MVPWorkshop) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [P2P](https://p2p.org/) | Multiblockchain ETL | [GitHub](https://github.com/p2p-org/polkadot-profit-transformer) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [FlexDapps](https://flexdapps.com/) | Gantree Phase 4 | [GitHub](https://github.com/flex-dapps) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Zondax](http://zondax.ch/) | Ledgeracio: A command-line tool and Ledger app designed for staking operations | [GitHub](https://github.com/paritytech/ledgeracio) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Dipole Tech](https://www.dipole.tech) | Dipole Oracle: Distributed energy resource management | [GitHub](https://github.com/DipoleTech/dipole-oracle) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 7 - Third Quarter 2020 +| [Protofire](https://protofire.io/) | Failover mechanism for validators | [GitHub](https://github.com/protofire) | ☐ | ☒ | ☒ | +| [HashQuark](https://www.hashquark.io/) | Validator Dashboard Phase 2 | [GitHub](https://github.com/hashquark-io) | ☐ | ☒ | ☒ | +| [BUIDL Labs](https://buidllabs.io/) | YieldScan Staking Dashboard | [GitHub](https://github.com/buidl-labs) | ☐ | ☒ | ☒ | +| BoBao Technologies | PolkaKey an electron app to generate Polkadot addresses + tutorials | [GitHub](https://github.com/w3finance/PolkaKey) | ☐ | ☒ | ☐ | +| [Webassembly Security](https://webassembly-security.com/) | Improving security and resilience of WebAssembly runtimes | [GitHub](https://github.com/pventuzelo/wasm_runtimes_fuzzing) | ☐ | ☒ | ☒ | +| [Finoa](https://finoa.io/) | C library for Substrate | [GitHub](https://github.com/finoabanking/substrate-c-tool) | ☐ | ☒ | ☒ | +| [Crust Network](https://crust.network/) | Incentive layer protocol for decentralized storage | [GitHub](https://github.com/crustio) | ☐ | ☒ | ☒ | +| [ETCDEV](https://emeraldpay.io/) | Polkadot Java Client | [GitHub](https://github.com/emeraldpay) | ☐ | ☒ | ☒ | +| [Zondax](http://zondax.ch/) | Ledger app for Polkadot/Kusama Phase 2 | [GitHub](https://github.com/ZondaX/ledger-polkadot) | ☐ | ☒ | ☒ | +| [Soramitsu](https://soramitsu.co.jp/) | Hyperledger Iroha Bridge | [GitHub](https://github.com/sora-xor/polkaswap-web) | ☐ | ☒ | ☒ | +| [LimeChain](https://github.com/LimeChain) | AssemblyScript SCALE Codec | [GitHub](https://github.com/LimeChain/as-scale-codec) | ☐ | ☒ | ☒ | +| [Insight](https://insightfellows.com/) | Load Balanced Endpoints | [GitHub](https://github.com/insight-w3f/terragrunt-polkadot) | ☐ | ☒ | ☒ | +| [Ethworks](https://ethworks.io/) | Polkadot.{js} Desktop Application | [GitHub](https://github.com/EthWorks/) | ☐ | ☒ | ☒ | +| [Usetech](http://usetech.com/blockchain.html) | NFT Tracking Module | [GitHub](https://github.com/usetech-llc/nft_parachain) | ☐ | ☒ | ☒ | +| [Chevdor](https://www.chevdor.com/) | Polkabot | [GitHub](https://github.com/chevdor) | ☐ | ☒ | ☒ | +| [Aleksandr Krupenkin](https://github.com/akru) | Haskell Web3 library | [GitHub](https://github.com/airalab/hs-web3) | ☐ | ☒ | ☒ | +| [WEB3SCAN](https://www.web3scan.com/) | Polkascan Signer Interfaces | [GitHub](https://github.com/polkascan) | ☐ | ☒ | ☒ | +| [Fortmatic](https://fortmatic.com/) | SDK + Burner Wallet to implement Web 2.0 login for dapps | [GitHub](https://github.com/fortmatic) | ☐ | ☐ | ☐ | +| [PureStake](https://www.purestake.com/) | Web3 Compatible API | [GitHub](https://github.com/PureStake) | ☐ | ☒ | ☒ | +| [Phala.Network](https://phala.network/) | Web3 Analytics | [GitHub](https://github.com/Phala-Network/) | ☐ | ☐ | ☐ | +| [TerenceGe](https://github.com/TerenceGe) | C implementation of Schnorrkel | [GitHub](https://github.com/TerenceGe/sr25519-donna) | ☐ | ☒ | ☒ | +| [Adoriasoft](https://adoriasoft.com/) | Cosmos-SDK Parachain Development Kit | [GitHub](https://github.com/adoriasoft/cosmos-sdk) | ☐ | ☒ | ☒ | +| [Laminar One](https://laminar.one/) | Reusable Libraries: Runtime Modules + Monitoring Framework | [GitHub](https://github.com/open-web3-stack) | ☐ | ☒ | ☒ | +| [Faber](https://github.com/yxf) | Subwallet: CLI wallet for Polkadot/Substrate | [GitHub](https://github.com/yxf/subwallet) | ☐ | ☒ | ☒ | +| [Equilibrium.co](https://equilibrium.co/) | offchain::ipfs | [GitHub](https://github.com/eqlabs) | ☐ | ☒ | ☒ | +| [Snowfork](http://www.snowfork.com/) | Ethereum Bridge | [GitHub](https://github.com/snowfork) | ☐ | ☒ | ☒ | +| [Lunie](http://lunie.io/) | Lunie Governance integration | [GitHub](https://github.com/luniehq/lunie) | ☐ | ☒ | ☒ | +| [LimeChain](https://github.com/LimeChain) | AssemblyScript Runtime | [GitHub](https://github.com/LimeChain) | ☐ | ☒ | ☒ | +| [MVP Workshop](https://mvpworkshop.co/) | Substrate startkit GUI (marketplace for substrate pallets) | [GitHub](https://github.com/MVPWorkshop) | ☐ | ☒ | ☒ | +| [P2P](https://p2p.org/) | Multiblockchain ETL | [GitHub](https://github.com/p2p-org/polkadot-profit-transformer) | ☐ | ☒ | ☒ | +| [FlexDapps](https://flexdapps.com/) | Gantree Phase 4 | [GitHub](https://github.com/flex-dapps) | ☐ | ☐ | ☐ | +| [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 | [GitHub](https://github.com/DipoleTech/dipole-oracle) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 7 - Third Quarter 2020 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Halva](https://github.com/halva-suite) | A toolchain for improving the experience of developing Decentralized Applications based on Substrate | [GitHub](https://github.com/halva-suite) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Subscan](subscan.io) | Substrate explorer | [GitHub](https://github.com/itering/subscan) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [t3rn](https://github.com/t3rn/t3rn) | A protocol for blockchain interoperability | [GitHub](https://github.com/t3rn/t3rn) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stake Technologies](https://stake.co.jp/) | Hardware ECDSA for Polkadot JS | [GitHub](https://github.com/polkadot-js) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Protofire](https://protofire.io/) | Failover mechanism for validators upgrade | [GitHub](https://github.com/protofire) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [DappForce](http://dappforce.io) | SubSocial Chapter 2 | [GitHub](https://github.com/dappforce/dappforce-subsocial) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [OpenSquare Network](https://www.opensquare.network/) | A blockchain based crowdsourcing and reputation platform | [GitHub](https://github.com/opensquare-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Cardinals](https://cardinals.cc/) | Threshold BLS Randomness Beacon for Substrate | [GitLab](https://gitlab.com/cardinals1/threshold-ecdsa) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [KILT](https://kilt.io/) | Polimec: A Fundraising Mechanism for Projects within the Polkadot Ecosystem | [GitHub](https://github.com/KILTprotocol) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Simply VC](https://simply-vc.com.mt/) | P.A.N.I.C. Phase 2 | [GitHub](https://github.com/SimplyVC/panic_polkadot) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Interlay](https://www.interlay.io/) | Trustless BTC-Polkadot Bridge | [GitLab](https://gitlab.com/interlay) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [enfipy](https://github.com/enfipy) | Creator: Mobile Game Framework for Substrate | [GitHub](https://github.com/creator-rs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Halva](https://github.com/halva-suite) | Halva: Bootstrapping and Scaffolding | [GitHub](https://github.com/halva-suite) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Sunshine Systems](https://sunshine.foundation) | Sunshine Keybase | [GitHub](https://github.com/sunshine-protocol) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Subscan](subscan.io) | Multi-signature Management Tool | [GitHub](https://github.com/itering) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Evercity](https://evercity.io/) | Smart Sustainable Bond Protocol (SSB-P) | [GitHub](https://github.com/EvercityEcosystem/Smart-Sustainable-Bond) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Permiurly](http://permiurly.in) | Polkassembly | [GitHub](https://github.com/premiurly/polkassembly) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zeropool](https://zeropool.network/) | Private transactions on Polkadot | [GitHub](https://github.com/zeropoolnetwork) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Polkadex](https://github.com/Polkadex-Substrate) | A decentralized, peer-peer, cryptocurrency exchange for DeFi ecosystem in Substrate | [GitHub](https://github.com/Polkadex-Substrate/Polkadex) |
  • [x]
|
  • [x]
|
  • [ ]
| -| [Fractapp](https://fractapp.com) | Messenger with crypto wallet | [GitHub](https://github.com/fractapp) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Equilibrium.io](https://equilibrium.io/en) | All-in-one Interoperable DeFi hub. | [GitHub](https://github.com/equilibrium-eosdt) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Glacier Blockchain Technology](http://www.gbctech.cn/#/) | Starks Network | [GitHub](https://github.com/gbctech) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SubDEX](http://subdex.io.s3.eu-west-2.amazonaws.com/index.html) | A decentralized cross-chain exchange based on AMM | [GitHub](https://github.com/subdarkdex) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zenlink](https://zenlink.pro/) | A cross-chain DEX network | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Subscript](https://github.com/slickup) | Substrate smart contract api and sdk in AssemblyScript | [GitHub](https://github.com/slickup/subscript) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Tesseract](https://tesseract.one/) | Swift API | [GitHub](https://github.com/tesseract-one) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Cobo](https://cobo.com/) | Cobo Vault | [GitHub](https://github.com/CoboVault) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [NodeFactory](https://nodefactory.io/) | Vedran: Auto-funded public p2p infrastructure (APPI) | [GitHub](https://github.com/NodeFactoryIo/Vedran) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Adoriasoft](https://adoriasoft.com/) | Cosmos-SDK Parachain Development Kit Phase 2 | [GitHub](https://github.com/adoriasoft/cosmos-sdk) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [sup](https://github.com/clearloop/sup) | Command line tool for generating or upgrading a Substrate node | [GitHub](https://github.com/clearloop/sup) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Shard Labs](https://shardlabs.io) | Tip or Donate KSM Embeddable Button | [GitHub](https://github.com/Shard-Labs) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 8 - Fourth Quarter 2020 +| [Halva](https://github.com/halva-suite) | A toolchain for improving the experience of developing Decentralized Applications based on Substrate | [GitHub](https://github.com/halva-suite) | ☐ | ☒ | ☒ | +| [Subscan](subscan.io) | Substrate explorer | [GitHub](https://github.com/itering/subscan) | ☐ | ☒ | ☒ | +| [t3rn](https://github.com/t3rn/t3rn) | A protocol for blockchain interoperability | [GitHub](https://github.com/t3rn/t3rn) | ☐ | ☒ | ☒ | +| [Stake Technologies](https://stake.co.jp/) | Hardware ECDSA for Polkadot JS | [GitHub](https://github.com/polkadot-js) | ☐ | ☐ | ☐ | +| [Protofire](https://protofire.io/) | Failover mechanism for validators upgrade | [GitHub](https://github.com/protofire) | ☐ | ☒ | ☐ | +| [DappForce](http://dappforce.io) | SubSocial Chapter 2 | [GitHub](https://github.com/dappforce/dappforce-subsocial) | ☐ | ☒ | ☒ | +| [OpenSquare Network](https://www.opensquare.network/) | A blockchain based crowdsourcing and reputation platform | [GitHub](https://github.com/opensquare-network) | ☐ | ☒ | ☒ | +| [Cardinals](https://cardinals.cc/) | Threshold BLS Randomness Beacon for Substrate | [GitLab](https://gitlab.com/cardinals1/threshold-ecdsa) | ☐ | ☒ | ☒ | +| [KILT](https://kilt.io/) | Polimec: A Fundraising Mechanism for Projects within the Polkadot Ecosystem | [GitHub](https://github.com/KILTprotocol) | ☐ | ☐ | ☐ | +| [Simply VC](https://simply-vc.com.mt/) | P.A.N.I.C. Phase 2 | [GitHub](https://github.com/SimplyVC/panic_polkadot) | ☐ | ☐ | ☐ | +| [Interlay](https://www.interlay.io/) | Trustless BTC-Polkadot Bridge | [GitLab](https://gitlab.com/interlay) | ☐ | ☒ | ☐ | +| [enfipy](https://github.com/enfipy) | Creator: Mobile Game Framework for Substrate | [GitHub](https://github.com/creator-rs) | ☐ | ☒ | ☒ | +| [Halva](https://github.com/halva-suite) | Halva: Bootstrapping and Scaffolding | [GitHub](https://github.com/halva-suite) | ☐ | ☒ | ☒ | +| [Sunshine Systems](https://sunshine.foundation) | Sunshine Keybase | [GitHub](https://github.com/sunshine-protocol) | ☐ | ☒ | ☒ | +| [Subscan](subscan.io) | Multi-signature Management Tool | [GitHub](https://github.com/itering) | ☐ | ☒ | ☒ | +| [Evercity](https://evercity.io/) | Smart Sustainable Bond Protocol (SSB-P) | [GitHub](https://github.com/EvercityEcosystem/Smart-Sustainable-Bond) | ☐ | ☒ | ☒ | +| [Permiurly](http://permiurly.in) | Polkassembly | [GitHub](https://github.com/premiurly/polkassembly) | ☐ | ☒ | ☒ | +| [Zeropool](https://zeropool.network/) | Private transactions on Polkadot | [GitHub](https://github.com/zeropoolnetwork) | ☐ | ☒ | ☐ | +| [Polkadex](https://github.com/Polkadex-Substrate) | A decentralized, peer-peer, cryptocurrency exchange for DeFi ecosystem in Substrate | [GitHub](https://github.com/Polkadex-Substrate/Polkadex) | ☒ | ☒ | ☐ | +| [Fractapp](https://fractapp.com) | Messenger with crypto wallet | [GitHub](https://github.com/fractapp) | ☐ | ☒ | ☒ | +| [Equilibrium.io](https://equilibrium.io/en) | All-in-one Interoperable DeFi hub. | [GitHub](https://github.com/equilibrium-eosdt) | ☐ | ☒ | ☒ | +| [Glacier Blockchain Technology](http://www.gbctech.cn/#/) | Starks Network | [GitHub](https://github.com/gbctech) | ☐ | ☒ | ☒ | +| [SubDEX](http://subdex.io.s3.eu-west-2.amazonaws.com/index.html) | A decentralized cross-chain exchange based on AMM | [GitHub](https://github.com/subdarkdex) | ☐ | ☒ | ☒ | +| [Zenlink](https://zenlink.pro/) | A cross-chain DEX network | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) | ☐ | ☒ | ☒ | +| [Subscript](https://github.com/slickup) | Substrate smart contract api and sdk in AssemblyScript | [GitHub](https://github.com/slickup/subscript) | ☐ | ☒ | ☒ | +| [Tesseract](https://tesseract.one/) | Swift API | [GitHub](https://github.com/tesseract-one) | ☐ | ☒ | ☐ | +| [Cobo](https://cobo.com/) | Cobo Vault | [GitHub](https://github.com/CoboVault) | ☐ | ☒ | ☒ | +| [NodeFactory](https://nodefactory.io/) | Vedran: Auto-funded public p2p infrastructure (APPI) | [GitHub](https://github.com/NodeFactoryIo/Vedran) | ☐ | ☒ | ☒ | +| [Adoriasoft](https://adoriasoft.com/) | Cosmos-SDK Parachain Development Kit Phase 2 | [GitHub](https://github.com/adoriasoft/cosmos-sdk) | ☐ | ☒ | ☒ | +| [sup](https://github.com/clearloop/sup) | Command line tool for generating or upgrading a Substrate node | [GitHub](https://github.com/clearloop/sup) | ☐ | ☒ | ☒ | +| [Shard Labs](https://shardlabs.io) | Tip or Donate KSM Embeddable Button | [GitHub](https://github.com/Shard-Labs) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 8 - Fourth Quarter 2020 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Sean Young](https://www.mess.org/) | Solidity to WASM compiler Phase 2 | [GitHub](https://github.com/hyperledger-labs/solang) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Nuclei Studio](https://nuclei.studio/) | Governance OS | [GitHub](https://github.com/NucleiStudio) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [NBLTrust](https://www.nbltrust.com/#/en/home) | Dart SCALE Codec | [GitHub](https://github.com/nbltrust/dart-scale-codec) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Nsure.Network](https://nsure.network/) | Open Insurance Platform for Open Finance | [GitHub](https://github.com/nsure-tech) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Kylin Network](https://kylin.network/) | Cross-chain Platform for the Data Economy | [GitHub](https://github.com/Kylin-Network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Bit.Country](http://bit.country/) | A decentralized world | [GitHub](https://github.com/bit-country) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [MIDL.dev](https://MIDL.dev) | Polkashots.io: Snapshot website for Polkadot and Kusama | [GitHub](https://github.com/midl-dev) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Ares Protocol](https://www.aresprotocol.com/) | Decentralized Oracle Protocol | [GitHub](https://github.com/aresprotocols/ares) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Saito](https://saito.io/) | Polkadot Gaming Protocol and Library | [GitHub](https://github.com/SaitoTech) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [LimeChain](https://github.com/LimeChain) | Subsembly: Framework for building AssemblyScript Runtimes | [GitHub](https://github.com/LimeChain) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Wificoin](https://wificoin.com/) | PESA: On-ramp/off-ramp to crypto/local currencies for Polkadot | |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [WalletConnect](https://walletconnect.org/) | Open protocol for connecting Wallets to Dapps | [GitHub](https://github.com/walletconnect) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Citadel.one](https://citadel.one/) | Non-custodial Proof-of-Stake platform | |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Geometry Labs](https://geometrylabs.io/) | Load Balanced Endpoints Phase 2 | [GitHub](https://github.com/geometry-labs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [MAP labs](https://www.maplabs.io/) | Map Bridge: Connect Polkadot and other PoW chains | [GitHub](https://github.com/Philasande-map/mapbridge) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [RareLink](http://rarelink.network/) | Dynamic non-fungible token (NFT) Protocol | [GitHub](https://github.com/RareLink) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Cere Network](http://cere.network/) | Turnkey Private Blockchain Network | [GitHub](https://github.com/Cerebellum-Network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SubDAO Labs](https://www.subdao.network/) | SubDAO is a Cross-chain Platform to link DAO and DApp on Polkadot | [GitHub](https://github.com/subdao-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Idavoll Network](https://idavoll.network/) | Decentralized organization platform | [GitHub](https://github.com/idavollnetwork) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zenlink](https://zenlink.pro/) | DEX Ink! smart contract | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Setheum](https://setheum.xyz/) | Setheum Elastic Reserve Protocol | [GitHub](https://github.com/Setheum-Labs/Setheum) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [everstake](https://everstake.one/) | DKG msig wallet | [GitHub](https://github.com/everstake) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Coinversation](http://coinversation.cn/) | Decentralized exchange for trading synthetic assets | [GitHub](https://github.com/Coinversation) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [Manta Network](https://www.manta.network/) | A Privacy Preserving Decentralized Exchange | [GitHub](https://github.com/Manta-Network) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Stake Technologies](https://stake.co.jp/en/) | ZK Rollups Pallet | [GitHub](https://github.com/staketechnologies) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Apron Network](https://apron.network/) | Decentralized infrastructure provider | [GitHub](https://github.com/apron-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Pocket 4D](https://pocket4d.io) | Substrate Dart API client | [GitHub](https://github.com/Pocket4D) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Listen](https://listen.io/) | Decentralized social network focusing on sound | [GitHub](https://github.com/ListenTeam) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [Protofire](https://protofire.io/) | Polkadot Mempool Explorer | [GitHub](https://github.com/protofire) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Fuzhou Wakanda Information Technology](https://www.heizuan.com/) | Black Diamond Wallet | [GitHub](https://github.com/bdwallet) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Konomi](http://konomi.network/) | Pool Lending Module | [GitHub](https://github.com/konomi-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Acala](https://acala.network/) | Bodhi:Composable & Innovative Stack for EVM | [GitHub](https://github.com/AcalaNetwork/bodhi.js) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Pontem Network](https://pontem.network/) | Move smart contract pallet | [GitHub](https://github.com/dfinance) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SpiderDAO](https://spiderdao.io) | Hardware-based DAO governance | [GitHub](https://github.com/SpiderDAO) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [onfinality](https://onfinality.io) | Subquery: Open-source tool to process and query data | [GitHub](https://github.com/onfinality-io) |
  • [ ]
|
  • [x]
|
  • [x]
| -| FOS Foundation LTD | Pacific store: OpenSea.js on polkadot | [GitHub](https://github.com/vlbos) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Polkadot Technology Alliance](https://polkachina.org) | Shadows Network: synthetic assets | [GitHub](https://github.com/ShadowsNetwork) |
  • [x]
|
  • [x]
|
  • [ ]
| -| [BLDG BLOX](https://bldg.app/) | ESG (Environmental, Social, and Corporate Governance) ratings dashboard | [GitHub](https://github.com/BLDG-BLOX/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [DEIPWORLD](https://deip.world/) | IP Management/Governance Module | [GitHub](https://github.com/DEIPworld) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Deeper.Network](https://deeper.network/) | Micropayments pallet | [GitHub](https://github.com/e2chain-dev/deeper-chain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Evanesco](https://evanesco.org/) | Private network protocol | [GitHub](https://github.com/Evanesco-Labs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [HugoByte](https://hugobyte.com/) | Project Aurras: Event Manager | [GitHub](https://github.com/HugoByte) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Bounce Protocol](https://bounce.finance/) | Decentralized Auction Protocol | [GitHub](https://github.com/bouncefinance/bounce-network) |
  • [ ]
|
  • [ ]
|
  • [ ]
| +| [Sean Young](https://www.mess.org/) | Solidity to WASM compiler Phase 2 | [GitHub](https://github.com/hyperledger-labs/solang) | ☐ | ☒ | ☒ | +| [Nuclei Studio](https://nuclei.studio/) | Governance OS | [GitHub](https://github.com/NucleiStudio) | ☐ | ☒ | ☒ | +| [NBLTrust](https://www.nbltrust.com/#/en/home) | Dart SCALE Codec | [GitHub](https://github.com/nbltrust/dart-scale-codec) | ☐ | ☒ | ☒ | +| [Nsure.Network](https://nsure.network/) | Open Insurance Platform for Open Finance | [GitHub](https://github.com/nsure-tech) | ☐ | ☒ | ☐ | +| [Kylin Network](https://kylin.network/) | Cross-chain Platform for the Data Economy | [GitHub](https://github.com/Kylin-Network) | ☐ | ☒ | ☒ | +| [Bit.Country](http://bit.country/) | A decentralized world | [GitHub](https://github.com/bit-country) | ☐ | ☒ | ☒ | +| [MIDL.dev](https://MIDL.dev) | Polkashots.io: Snapshot website for Polkadot and Kusama | [GitHub](https://github.com/midl-dev) | ☐ | ☒ | ☒ | +| [Ares Protocol](https://www.aresprotocol.com/) | Decentralized Oracle Protocol | [GitHub](https://github.com/aresprotocols/ares) | ☐ | ☒ | ☒ | +| [Saito](https://saito.io/) | Polkadot Gaming Protocol and Library | [GitHub](https://github.com/SaitoTech) | ☐ | ☒ | ☐ | +| [LimeChain](https://github.com/LimeChain) | Subsembly: Framework for building AssemblyScript Runtimes | [GitHub](https://github.com/LimeChain) | ☐ | ☒ | ☐ | +| [Wificoin](https://wificoin.com/) | PESA: On-ramp/off-ramp to crypto/local currencies for Polkadot | | ☐ | ☐ | ☐ | +| [WalletConnect](https://walletconnect.org/) | Open protocol for connecting Wallets to Dapps | [GitHub](https://github.com/walletconnect) | ☐ | ☒ | ☐ | +| [Citadel.one](https://citadel.one/) | Non-custodial Proof-of-Stake platform | | ☐ | ☒ | ☒ | +| [Geometry Labs](https://geometrylabs.io/) | Load Balanced Endpoints Phase 2 | [GitHub](https://github.com/geometry-labs) | ☐ | ☒ | ☒ | +| [MAP labs](https://www.maplabs.io/) | Map Bridge: Connect Polkadot and other PoW chains | [GitHub](https://github.com/Philasande-map/mapbridge) | ☒ | ☐ | ☐ | +| [RareLink](http://rarelink.network/) | Dynamic non-fungible token (NFT) Protocol | [GitHub](https://github.com/RareLink) | ☐ | ☐ | ☐ | +| [Cere Network](http://cere.network/) | Turnkey Private Blockchain Network | [GitHub](https://github.com/Cerebellum-Network) | ☐ | ☒ | ☒ | +| [SubDAO Labs](https://www.subdao.network/) | SubDAO is a Cross-chain Platform to link DAO and DApp on Polkadot | [GitHub](https://github.com/subdao-network) | ☐ | ☒ | ☒ | +| [Idavoll Network](https://idavoll.network/) | Decentralized organization platform | [GitHub](https://github.com/idavollnetwork) | ☐ | ☒ | ☒ | +| [Zenlink](https://zenlink.pro/) | DEX Ink! smart contract | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) | ☐ | ☐ | ☐ | +| [Setheum](https://setheum.xyz/) | Setheum Elastic Reserve Protocol | [GitHub](https://github.com/Setheum-Labs/Setheum) | ☒ | ☐ | ☐ | +| [everstake](https://everstake.one/) | DKG msig wallet | [GitHub](https://github.com/everstake) | ☐ | ☐ | ☐ | +| [Coinversation](http://coinversation.cn/) | Decentralized exchange for trading synthetic assets | [GitHub](https://github.com/Coinversation) | ☒ | ☐ | ☐ | +| [Manta Network](https://www.manta.network/) | A Privacy Preserving Decentralized Exchange | [GitHub](https://github.com/Manta-Network) | ☐ | ☒ | ☐ | +| [Stake Technologies](https://stake.co.jp/en/) | ZK Rollups Pallet | [GitHub](https://github.com/staketechnologies) | ☐ | ☒ | ☐ | +| [Apron Network](https://apron.network/) | Decentralized infrastructure provider | [GitHub](https://github.com/apron-network) | ☐ | ☒ | ☒ | +| [Pocket 4D](https://pocket4d.io) | Substrate Dart API client | [GitHub](https://github.com/Pocket4D) | ☐ | ☒ | ☐ | +| [Listen](https://listen.io/) | Decentralized social network focusing on sound | [GitHub](https://github.com/ListenTeam) | ☒ | ☐ | ☐ | +| [Protofire](https://protofire.io/) | Polkadot Mempool Explorer | [GitHub](https://github.com/protofire) | ☐ | ☒ | ☒ | +| [Fuzhou Wakanda Information Technology](https://www.heizuan.com/) | Black Diamond Wallet | [GitHub](https://github.com/bdwallet) | ☐ | ☐ | ☐ | +| [Konomi](http://konomi.network/) | Pool Lending Module | [GitHub](https://github.com/konomi-network) | ☐ | ☒ | ☒ | +| [Acala](https://acala.network/) | Bodhi:Composable & Innovative Stack for EVM | [GitHub](https://github.com/AcalaNetwork/bodhi.js) | ☐ | ☒ | ☒ | +| [Pontem Network](https://pontem.network/) | Move smart contract pallet | [GitHub](https://github.com/dfinance) | ☐ | ☒ | ☒ | +| [SpiderDAO](https://spiderdao.io) | Hardware-based DAO governance | [GitHub](https://github.com/SpiderDAO) | ☐ | ☐ | ☐ | +| [onfinality](https://onfinality.io) | Subquery: Open-source tool to process and query data | [GitHub](https://github.com/onfinality-io) | ☐ | ☒ | ☒ | +| FOS Foundation LTD | Pacific store: OpenSea.js on polkadot | [GitHub](https://github.com/vlbos) | ☐ | ☒ | ☐ | +| [Polkadot Technology Alliance](https://polkachina.org) | Shadows Network: synthetic assets | [GitHub](https://github.com/ShadowsNetwork) | ☒ | ☒ | ☐ | +| [BLDG BLOX](https://bldg.app/) | ESG (Environmental, Social, and Corporate Governance) ratings dashboard | [GitHub](https://github.com/BLDG-BLOX/) | ☐ | ☐ | ☐ | +| [DEIPWORLD](https://deip.world/) | IP Management/Governance Module | [GitHub](https://github.com/DEIPworld) | ☐ | ☒ | ☐ | +| [Deeper.Network](https://deeper.network/) | Micropayments pallet | [GitHub](https://github.com/e2chain-dev/deeper-chain) | ☐ | ☒ | ☒ | +| [Evanesco](https://evanesco.org/) | Private network protocol | [GitHub](https://github.com/Evanesco-Labs) | ☐ | ☒ | ☒ | +| [HugoByte](https://hugobyte.com/) | Project Aurras: Event Manager | [GitHub](https://github.com/HugoByte) | ☐ | ☒ | ☒ | +| [Bounce Protocol](https://bounce.finance/) | Decentralized Auction Protocol | [GitHub](https://github.com/bouncefinance/bounce-network) | ☐ | ☐ | ☐ | # 2021 -## :surfing_woman: Wave 9 - First Quarter 2021 +## 🏄‍♀️ Wave 9 - First Quarter 2021 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Zenlink](https://zenlink.pro/) | Cross-chain DEX | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [NFTT Studio](https://github.com/NFTT-studio) | NFT Store Pallet and Front End | [GitHub](https://github.com/NFTT-studio) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SubGame Network](https://subgame.org) | A decentralized game platform | [GitHub](https://github.com/SubGame-Network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Parami](https://parami.io) | Blockchain-empowered advertising alliance | [GitHub](https://github.com/parami-protocol/parami) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Sunrise Protocol](https://sunriseprotocol.com) | Sunrise DEX | [GitHub](https://github.com/sunriseprotocol) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Cobo](https://cobo.com/) | Cobo Vault Phase 2 | [GitHub](https://github.com/CoboVault) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [OxyDev](https://oxydev.ir) | SubsCrypt: Managing subscriptions | [GitHub](https://github.com/oxydev) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [DNFT-Team](https://github.com/DNFT-Team) | Data framework between personal data and AI models | [GitHub](https://github.com/DNFT-Team) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [UMC Labs](https://umc.network) | Secured token subscription | [GitHub](https://github.com/umc-network) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Perpetual Altruism Ltd](https://cryptograph.co/) | IP-Rights compliant NFT bridge protocol | [GitHub](https://github.com/Perpetual-Altruism-Ltd) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Clover](https://clover.finance/) | Easy-to-use blockchain infrastructure | [GitHub](https://github.com/clover-network/) |
  • [x]
|
  • [x]
|
  • [ ]
| -| [DoraHacks](https://dorahacks.com/) | Quadratic Funding Pallet | [GitHub](https://github.com/dorahacksglobal) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SEOR](https://www.seor.io) | Multi-chain smart contract development platform | [GitHub](https://github.com/SealSC) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Polkastarter](https://polkastarter.com/) | Crowdloan UI | [GitHub](https://github.com/polkastarter) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [Equilibrium.io](https://equilibrium.io/en) | Curve AMM Pallet | [GitHub](https://github.com/equilibrium-eosdt) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zondax](https://zondax.ch/) | Ledger maintenance + recovery extensions + support | [GitHub](https://github.com/Zondax) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Nuclei Studio](https://nuclei.studio/) | Voting Pallets | [GitHub](https://github.com/NucleiStudio) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [RAMP DEFI](https://app.rampdefi.com/#/) | Polkakeeper - A Community-Led Value Assurance Protocol | [GitHub](https://github.com/RAMP-DEFI) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Stone](https://stonedefi.io) | Index project which aims to track the portfolio of multiple digital assets | [GitHub](https://github.com/stonedefi/) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Reserve Labs](https://github.com/ReserveLabs) | AlgoCash - An algorithmic stablecoin | [GitHub](https://github.com/ReserveLabs/AlgoCash) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [gmajor](https://github.com/gmajor-encrypt) | PHP Scale Codec | [GitHub](https://github.com/gmajor-encrypt/php-scale-codec) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Trust Fractal GmbH](https://trustfractal.com/) | ink! Smart Contract Upgradeability | [GitHub](https://github.com/trustfractal/ink-upgrade-template) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Starry Network](https://github.com/Starry-Network) | Splittable NFTs | [GitHub](https://github.com/Starry-Network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Equilibrium](https://equilibrium.co/) | Research Storage Network| [GitHub](https://github.com/eqlabs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Ajuna](https://ajuna.io/) | Substrate .NET API | [GitHub](https://github.com/dotmog/SubstrateNetApi) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [NewOmega](https://github.com/WiktorStarczewski/newomega.trinity ) | A blockchain game that cannot be shut down | [GitHub](https://github.com/WiktorStarczewski/newomega.trinity ) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Bright Inventions](https://brightinventions.pl/) | Treasury Web application| [GitHub](https://github.com/bright/bright-tresury) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Standard protocol](https://github.com/standardweb3/standard-substrate) | A collateralized algorithmic stablecoin protocol for synthetic assets | [GitHub](https://github.com/standardweb3/standard-substrate) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Skye Kiwi](https://skye.kiwi/) | SkyePass: A decentralized, open source password manager | [GitHub](https://github.com/skyekiwi) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [RidOne Technologies](https://github.com/RidOne-technologies) | Polkadot UI Web + Angular Identicon | [GitHub](https://github.com/RidOne-technologies) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Zeropool](https://zeropool.network/) | Private transactions on Polkadot Phase 2 | [GitHub](https://github.com/zeropoolnetwork) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [OAK Foundation](https://oak.tech) | Quadratic Funding Module and Dapp Application | [GitHub](https://github.com/OAK-Foundation/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Commonwealth Labs](https://commonwealth.im/) | Webb Mixer| [GitHub](https://github.com/edgeware-builders) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [TEA Project](http://teaproject.org/) | Gluon - Decentralized Hardware Crypto Wallet Services | [GitHub](https://github.com/tearust) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Cycan Technologies](http://cycan.network/) | Everlasting Cash: A hybrid of a crypto-collateralized and an algorithmic stablecoin | [GitHub](https://github.com/CycanTech) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Shard Labs](https://shardlabs.io) | Substrate Identity Directory | [GitHub](https://github.com/Shard-Labs) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Lumena](https://www.lumena.tech) | A blockchain based EV charging platform | [GitHub](https://github.com/Delmonicos/charger-node) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [DEGO](https://dego.finance/) | Treasureland: An NFT publishing and trading platform | [GitHub](https://github.com/dego-labs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [AIKON](https://aikon.com/) | ChainJS integration | [GitHub](https://github.com/TeamAikon/chain-js) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Nathan Schwermann](https://github.com/nschwermann) | PolkaJ Android Support | [GitHub](https://github.com/nschwermann) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Acala](https://acala.network/) | xtokens - XCM Implementation for Fungible Assets | [GitHub](https://github.com/open-web3-stack/open-runtime-module-library/tree/master/xtokens) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [NUTS Finance](https://nuts.finance/) | Stable Asset | [GitHub](https://github.com/nutsfinance) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [MVP Workshop](https://mvpworkshop.co/) | pallet-maci (Minimal Anti Collusion Infrastructure) | [GitHub](https://github.com/MVPWorkshop) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [X-Predict](https://x-predict.com/) | Decentralized prediction market | [GitHub](https://github.com/XPredictMarket) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Chevdor](https://www.chevdor.com/) | SRTOOL App | [GitLab](https://gitlab.com/chevdor/srtool-app) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Bit.Country](http://bit.country/) | A decentralized world - Phase 2 | [GitHub](https://github.com/bit-country) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Vera](https://veraprotocol.org/) | NFT Lending + Exchange | [GitHub](https://github.com/veraprotocol) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Parallel Finance](https://parallel.fi/#/) | Decentralized lending/borrowing and staking protocol | [GitHub](https://github.com/parallel-finance/parallel) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 10 - Second Quarter 2021 +| [Zenlink](https://zenlink.pro/) | Cross-chain DEX | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) | ☐ | ☐ | ☐ | +| [NFTT Studio](https://github.com/NFTT-studio) | NFT Store Pallet and Front End | [GitHub](https://github.com/NFTT-studio) | ☐ | ☒ | ☒ | +| [SubGame Network](https://subgame.org) | A decentralized game platform | [GitHub](https://github.com/SubGame-Network) | ☐ | ☒ | ☒ | +| [Parami](https://parami.io) | Blockchain-empowered advertising alliance | [GitHub](https://github.com/parami-protocol/parami) | ☐ | ☐ | ☐ | +| [Sunrise Protocol](https://sunriseprotocol.com) | Sunrise DEX | [GitHub](https://github.com/sunriseprotocol) | ☐ | ☐ | ☐ | +| [Cobo](https://cobo.com/) | Cobo Vault Phase 2 | [GitHub](https://github.com/CoboVault) | ☐ | ☒ | ☐ | +| [OxyDev](https://oxydev.ir) | SubsCrypt: Managing subscriptions | [GitHub](https://github.com/oxydev) | ☐ | ☒ | ☐ | +| [DNFT-Team](https://github.com/DNFT-Team) | Data framework between personal data and AI models | [GitHub](https://github.com/DNFT-Team) | ☒ | ☐ | ☐ | +| [UMC Labs](https://umc.network) | Secured token subscription | [GitHub](https://github.com/umc-network) | ☐ | ☐ | ☐ | +| [Perpetual Altruism Ltd](https://cryptograph.co/) | IP-Rights compliant NFT bridge protocol | [GitHub](https://github.com/Perpetual-Altruism-Ltd) | ☐ | ☐ | ☐ | +| [Clover](https://clover.finance/) | Easy-to-use blockchain infrastructure | [GitHub](https://github.com/clover-network/) | ☒ | ☒ | ☐ | +| [DoraHacks](https://dorahacks.com/) | Quadratic Funding Pallet | [GitHub](https://github.com/dorahacksglobal) | ☐ | ☒ | ☒ | +| [SEOR](https://www.seor.io) | Multi-chain smart contract development platform | [GitHub](https://github.com/SealSC) | ☐ | ☒ | ☐ | +| [Polkastarter](https://polkastarter.com/) | Crowdloan UI | [GitHub](https://github.com/polkastarter) | ☒ | ☐ | ☐ | +| [Equilibrium.io](https://equilibrium.io/en) | Curve AMM Pallet | [GitHub](https://github.com/equilibrium-eosdt) | ☐ | ☒ | ☒ | +| [Zondax](https://zondax.ch/) | Ledger maintenance + recovery extensions + support | [GitHub](https://github.com/Zondax) | ☐ | ☒ | ☒ | +| [Nuclei Studio](https://nuclei.studio/) | Voting Pallets | [GitHub](https://github.com/NucleiStudio) | ☐ | ☒ | ☒ | +| [RAMP DEFI](https://app.rampdefi.com/#/) | Polkakeeper - A Community-Led Value Assurance Protocol | [GitHub](https://github.com/RAMP-DEFI) | ☐ | ☐ | ☐ | +| [Stone](https://stonedefi.io) | Index project which aims to track the portfolio of multiple digital assets | [GitHub](https://github.com/stonedefi/) | ☐ | ☒ | ☐ | +| [Reserve Labs](https://github.com/ReserveLabs) | AlgoCash - An algorithmic stablecoin | [GitHub](https://github.com/ReserveLabs/AlgoCash) | ☐ | ☒ | ☒ | +| [gmajor](https://github.com/gmajor-encrypt) | PHP Scale Codec | [GitHub](https://github.com/gmajor-encrypt/php-scale-codec) | ☐ | ☒ | ☒ | +| [Trust Fractal GmbH](https://trustfractal.com/) | ink! Smart Contract Upgradeability | [GitHub](https://github.com/trustfractal/ink-upgrade-template) | ☐ | ☒ | ☒ | +| [Starry Network](https://github.com/Starry-Network) | Splittable NFTs | [GitHub](https://github.com/Starry-Network) | ☐ | ☒ | ☒ | +| [Equilibrium](https://equilibrium.co/) | Research Storage Network| [GitHub](https://github.com/eqlabs) | ☐ | ☒ | ☒ | +| [Ajuna](https://ajuna.io/) | Substrate .NET API | [GitHub](https://github.com/dotmog/SubstrateNetApi) | ☐ | ☒ | ☒ | +| [NewOmega](https://github.com/WiktorStarczewski/newomega.trinity ) | A blockchain game that cannot be shut down | [GitHub](https://github.com/WiktorStarczewski/newomega.trinity ) | ☐ | ☒ | ☒ | +| [Bright Inventions](https://brightinventions.pl/) | Treasury Web application| [GitHub](https://github.com/bright/bright-tresury) | ☐ | ☒ | ☒ | +| [Standard protocol](https://github.com/standardweb3/standard-substrate) | A collateralized algorithmic stablecoin protocol for synthetic assets | [GitHub](https://github.com/standardweb3/standard-substrate) | ☐ | ☒ | ☐ | +| [Skye Kiwi](https://skye.kiwi/) | SkyePass: A decentralized, open source password manager | [GitHub](https://github.com/skyekiwi) | ☐ | ☒ | ☐ | +| [RidOne Technologies](https://github.com/RidOne-technologies) | Polkadot UI Web + Angular Identicon | [GitHub](https://github.com/RidOne-technologies) | ☐ | ☒ | ☒ | +| [Zeropool](https://zeropool.network/) | Private transactions on Polkadot Phase 2 | [GitHub](https://github.com/zeropoolnetwork) | ☐ | ☐ | ☐ | +| [OAK Foundation](https://oak.tech) | Quadratic Funding Module and Dapp Application | [GitHub](https://github.com/OAK-Foundation/) | ☐ | ☒ | ☒ | +| [Commonwealth Labs](https://commonwealth.im/) | Webb Mixer| [GitHub](https://github.com/edgeware-builders) | ☐ | ☒ | ☒ | +| [TEA Project](http://teaproject.org/) | Gluon - Decentralized Hardware Crypto Wallet Services | [GitHub](https://github.com/tearust) | ☐ | ☒ | ☐ | +| [Cycan Technologies](http://cycan.network/) | Everlasting Cash: A hybrid of a crypto-collateralized and an algorithmic stablecoin | [GitHub](https://github.com/CycanTech) | ☐ | ☐ | ☐ | +| [Shard Labs](https://shardlabs.io) | Substrate Identity Directory | [GitHub](https://github.com/Shard-Labs) | ☐ | ☒ | ☐ | +| [Lumena](https://www.lumena.tech) | A blockchain based EV charging platform | [GitHub](https://github.com/Delmonicos/charger-node) | ☐ | ☒ | ☒ | +| [DEGO](https://dego.finance/) | Treasureland: An NFT publishing and trading platform | [GitHub](https://github.com/dego-labs) | ☐ | ☐ | ☐ | +| [AIKON](https://aikon.com/) | ChainJS integration | [GitHub](https://github.com/TeamAikon/chain-js) | ☐ | ☐ | ☐ | +| [Nathan Schwermann](https://github.com/nschwermann) | PolkaJ Android Support | [GitHub](https://github.com/nschwermann) | ☐ | ☒ | ☐ | +| [Acala](https://acala.network/) | xtokens - XCM Implementation for Fungible Assets | [GitHub](https://github.com/open-web3-stack/open-runtime-module-library/tree/master/xtokens) | ☐ | ☒ | ☒ | +| [NUTS Finance](https://nuts.finance/) | Stable Asset | [GitHub](https://github.com/nutsfinance) | ☐ | ☒ | ☒ | +| [MVP Workshop](https://mvpworkshop.co/) | pallet-maci (Minimal Anti Collusion Infrastructure) | [GitHub](https://github.com/MVPWorkshop) | ☐ | ☐ | ☐ | +| [X-Predict](https://x-predict.com/) | Decentralized prediction market | [GitHub](https://github.com/XPredictMarket) | ☐ | ☐ | ☐ | +| [Chevdor](https://www.chevdor.com/) | SRTOOL App | [GitLab](https://gitlab.com/chevdor/srtool-app) | ☐ | ☒ | ☒ | +| [Bit.Country](http://bit.country/) | A decentralized world - Phase 2 | [GitHub](https://github.com/bit-country) | ☐ | ☒ | ☒ | +| [Vera](https://veraprotocol.org/) | NFT Lending + Exchange | [GitHub](https://github.com/veraprotocol) | ☐ | ☒ | ☒ | +| [Parallel Finance](https://parallel.fi/#/) | Decentralized lending/borrowing and staking protocol | [GitHub](https://github.com/parallel-finance/parallel) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 10 - Second Quarter 2021 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [GamePower](https://gamepower.network) | NFT Collectibles Wallet | [GitHub](https://github.com/GamePowerNetwork) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Subspace Labs](https://www.subspace.network/) | Proof-of-Capacity Consensus for Substrate | [GitHub](https://github.com/subspace) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ChainSafe](https://chainsafe.io/) | Go implementation of Cumulus | [GitHub](https://github.com/ChainSafeSystems) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Polkadotters](https://polkadotters.medium.com/) | Subauction| [GitHub](https://github.com/polkadotters/SubAuction) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Phala Network](https://phala.network/) | Open Node Framework| [GitHub](https://github.com/Tenet-X) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Ruby Protocol](http://rubyprotocol.com/) | Cryptographic Infrastructure for Data Monetization | [GitHub](https://github.com/Ruby-Protocol) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Find Signal Studio PTE. LTD.](https://yieldscan.app/) | YieldScan Phase 2 | [GitHub](https://github.com/yieldscan) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [PolkaMusic](https://polkamusic.io/) | Operating decentralized music businesses on blockchain | [GitHub](https://github.com/polkamusic/PolkaMusic) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [element36](https://element36.io) | FIAT on-off-ramp | [GitHub](https://github.com/element36-io) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Zondax](https://zondax.ch/) | Ledger Asset App | [GitHub](https://github.com/Zondax) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Moonbeam Network](https://moonbeam.network/) | Pallet-dPoS for Parachain Staking | [GitHub](https://github.com/PureStake/moonbeam) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Dora Factory](https://dorafactory.org/) | MolochDAO substrate pallets v1 and v2 | [GitHub](https://github.com/DoraFactory) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| BCANN | Blockchain system for Assigned Names And Numbers | [GitHub](https://github.com/weitaolee) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [MyBank Labs](https://mybank.network/) | Platform Bank, Social Network Bank, MyDeX and Credit Scoring System | [GitHub](https://github.com/mybank-network/mybank-network) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [ChainBridge Network](https://github.com/ChainBridgeNetworkTeam) | Doter: A browser extension wallet for Polkadot | [GitHub](https://github.com/ChainBridgeNetworkTeam) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SubDAO Labs](https://www.subdao.network/) | SubDAO Chrome Extension | [GitHub](https://github.com/subdao-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Sukhavati Labs](https://sukhavati.io/) | Sukhavati PoC Module | [GitHub](https://github.com/Sukhavati-Labs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [HypeLabs Inc.](https://hypelabs.io) | UpLink - Decentralized and infrastructure-free approach to peer-to-peer connectivity | [GitHub](https://github.com/Hype-Labs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| Jackson Harris III | Staking Rewards Viewer | [GitHub](https://github.com/jackson-harris-iii/staking-rewards-viewer) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Klevoya](https://klevoya.com/) | WASM Smart Contract Fuzzer | [GitHub](https://github.com/klevoya/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Perun Network](https://perun.network/) | Perun Channels | [GitHub](https://github.com/perun-network/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [NewOmega](https://github.com/WiktorStarczewski/newomega.trinity ) | A blockchain game that cannot be shut down (Milestone 3 and 4) | [GitHub](https://github.com/WiktorStarczewski/newomega.trinity ) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Webb Tech](https://www.webb.tools/) | Webb Mixer Extended | [GitHub](https://github.com/webb-tools) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Ajuna](https://ajuna.io/) | UnitySDK for Substrate | [GitHub](https://github.com/JetonNetwork) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Canyon Labs](https://canyon-network.io) | Permanent decentralized storage | [GitHub](https://github.com/canyon-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ZeroDAO Network](https://zerodao.net/) | Decentralised reputation systems and social networks | [GitHub](https://github.com/ZeroDAO) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stake Technologies](https://stake.co.jp/) | ZK Plonk Pallet | [GitHub](https://github.com/PlasmNetwork) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [CryptoLab](https://www.cryptolab.network) | Staking Reward Collector | [GitHub](https://github.com/cryptolab-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Yatima Inc](https://github.com/yatima-inc/yatima) | Lambda-VM and programming language for Substrate | [GitHub](https://github.com/yatima-inc/yatima) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 11 - Third Quarter 2021 +| [GamePower](https://gamepower.network) | NFT Collectibles Wallet | [GitHub](https://github.com/GamePowerNetwork) | ☐ | ☒ | ☐ | +| [Subspace Labs](https://www.subspace.network/) | Proof-of-Capacity Consensus for Substrate | [GitHub](https://github.com/subspace) | ☐ | ☒ | ☒ | +| [ChainSafe](https://chainsafe.io/) | Go implementation of Cumulus | [GitHub](https://github.com/ChainSafeSystems) | ☐ | ☐ | ☐ | +| [Polkadotters](https://polkadotters.medium.com/) | Subauction| [GitHub](https://github.com/polkadotters/SubAuction) | ☐ | ☒ | ☒ | +| [Phala Network](https://phala.network/) | Open Node Framework| [GitHub](https://github.com/Tenet-X) | ☐ | ☐ | ☐ | +| [Ruby Protocol](http://rubyprotocol.com/) | Cryptographic Infrastructure for Data Monetization | [GitHub](https://github.com/Ruby-Protocol) | ☐ | ☒ | ☒ | +| [Find Signal Studio PTE. LTD.](https://yieldscan.app/) | YieldScan Phase 2 | [GitHub](https://github.com/yieldscan) | ☐ | ☒ | ☒ | +| [PolkaMusic](https://polkamusic.io/) | Operating decentralized music businesses on blockchain | [GitHub](https://github.com/polkamusic/PolkaMusic) | ☐ | ☒ | ☐ | +| [element36](https://element36.io) | FIAT on-off-ramp | [GitHub](https://github.com/element36-io) | ☐ | ☒ | ☐ | +| [Zondax](https://zondax.ch/) | Ledger Asset App | [GitHub](https://github.com/Zondax) | ☐ | ☒ | ☒ | +| [Moonbeam Network](https://moonbeam.network/) | Pallet-dPoS for Parachain Staking | [GitHub](https://github.com/PureStake/moonbeam) | ☐ | ☒ | ☒ | +| [Dora Factory](https://dorafactory.org/) | MolochDAO substrate pallets v1 and v2 | [GitHub](https://github.com/DoraFactory) | ☐ | ☒ | ☐ | +| BCANN | Blockchain system for Assigned Names And Numbers | [GitHub](https://github.com/weitaolee) | ☐ | ☐ | ☐ | +| [MyBank Labs](https://mybank.network/) | Platform Bank, Social Network Bank, MyDeX and Credit Scoring System | [GitHub](https://github.com/mybank-network/mybank-network) | ☐ | ☐ | ☐ | +| [ChainBridge Network](https://github.com/ChainBridgeNetworkTeam) | Doter: A browser extension wallet for Polkadot | [GitHub](https://github.com/ChainBridgeNetworkTeam) | ☐ | ☒ | ☒ | +| [SubDAO Labs](https://www.subdao.network/) | SubDAO Chrome Extension | [GitHub](https://github.com/subdao-network) | ☐ | ☒ | ☒ | +| [Sukhavati Labs](https://sukhavati.io/) | Sukhavati PoC Module | [GitHub](https://github.com/Sukhavati-Labs) | ☐ | ☐ | ☐ | +| [HypeLabs Inc.](https://hypelabs.io) | UpLink - Decentralized and infrastructure-free approach to peer-to-peer connectivity | [GitHub](https://github.com/Hype-Labs) | ☐ | ☐ | ☐ | +| Jackson Harris III | Staking Rewards Viewer | [GitHub](https://github.com/jackson-harris-iii/staking-rewards-viewer) | ☐ | ☐ | ☐ | +| [Klevoya](https://klevoya.com/) | WASM Smart Contract Fuzzer | [GitHub](https://github.com/klevoya/) | ☐ | ☐ | ☐ | +| [Perun Network](https://perun.network/) | Perun Channels | [GitHub](https://github.com/perun-network/) | ☐ | ☒ | ☒ | +| [NewOmega](https://github.com/WiktorStarczewski/newomega.trinity ) | A blockchain game that cannot be shut down (Milestone 3 and 4) | [GitHub](https://github.com/WiktorStarczewski/newomega.trinity ) | ☐ | ☒ | ☒ | +| [Webb Tech](https://www.webb.tools/) | Webb Mixer Extended | [GitHub](https://github.com/webb-tools) | ☐ | ☒ | ☒ | +| [Ajuna](https://ajuna.io/) | UnitySDK for Substrate | [GitHub](https://github.com/JetonNetwork) | ☐ | ☒ | ☐ | +| [Canyon Labs](https://canyon-network.io) | Permanent decentralized storage | [GitHub](https://github.com/canyon-network) | ☐ | ☒ | ☒ | +| [ZeroDAO Network](https://zerodao.net/) | Decentralised reputation systems and social networks | [GitHub](https://github.com/ZeroDAO) | ☐ | ☒ | ☒ | +| [Stake Technologies](https://stake.co.jp/) | ZK Plonk Pallet | [GitHub](https://github.com/PlasmNetwork) | ☐ | ☒ | ☒ | +| [CryptoLab](https://www.cryptolab.network) | Staking Reward Collector | [GitHub](https://github.com/cryptolab-network) | ☐ | ☒ | ☒ | +| [Yatima Inc](https://github.com/yatima-inc/yatima) | Lambda-VM and programming language for Substrate | [GitHub](https://github.com/yatima-inc/yatima) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 11 - Third Quarter 2021 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Pawn](https://github.com/pawnz0) | NuLink | [GitHub](https://github.com/pawnz0/NuLink) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Cyril Carlier](https://github.com/CrommVardek) | Polk-Auction Website | [GitHub](https://github.com/CrommVardek) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Uddug](https://uddug.com/) | JuniDB - Peer-to-Peer Databases | [GitHub](http://github.com/uddugteam/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Canyon Labs](https://canyon-network.io) | Permanent decentralized storage Phase 2 | [GitHub](https://github.com/canyon-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Skynet Labs](https://siasky.net/) | Pallet for Decentralized Off-Chain Storage on Skynet | [GitHub](https://gitlab.com/SkynetLabs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Uniwrap/1001 Group](https://uniwrap.io/) | Project 1001 | [GitHub](https://github.com/uniwrap-protocol) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [YibanChen](https://yibanchen.com) | Notes DApp & Site-Pallet | [GitHub](https://github.com/YibanChen/) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [SuperColony](https://github.com/Supercolony-net) | OpenBrush - Secure smart-contract development on ink! | [GitHub](https://github.com/Supercolony-net) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Banksy Finance](http://www.banksy.finance/) | NFT Pool-Based Lending Hub | [GitHub](https://github.com/Banksy-Finance) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [SubDAO Labs](https://www.subdao.network/) | PolkaSign - Web3.0 app for electronic agreements | [GitHub](https://github.com/subdao-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Valibre](https://valibre.org) | People Local Interactions Protocol (PLIP) | [GitHub](https://github.com/valibre-org/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Reaudito](https://shivarthu.reaudito.com/#/) | Shivarthu: A blockchain-based decentralized governance system | [GitHub](https://github.com/amiyatulu/shivarthu) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| Uniscan | NFT Explorer | [GitHub](https://github.com/wuminzhe) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [LimeChain](https://limechain.tech) | Subsembly - Support for GRANDPA | [GitHub](https://github.com/LimeChain) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [OpenSquare](https://www.opensquare.network) | Off-chain voting platform | [GitHub](https://github.com/opensquare-network/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Health Hero](https://www.gohealthhero.com/) | NFT Product Analytics Suite | |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Tesseract](https://tesseract.one/) | Mobile dApps/Wallet Connection | [GitHub](https://github.com/tesseract-one) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Wow Labz](http://www.wowlabz.com) | Dot Marketplace | [GitHub](https://github.com/WowLabz) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Perun Network](https://perun.network/) | Perun Channels - Integration with go-perun | [GitHub](https://github.com/perun-network/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [InvArchitects](https://www.invarch.io/) | InvArch - IP Infrastructure for Substrate | [GitHub](https://github.com/InvArch) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SubGame Network](https://subgame.org) | A decentralized game platform Phase 2| [GitHub](https://github.com/SubGame-Network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [CESS LAB](https://www.cess.cloud/) | Cumulus Encrypted Storage System (CESS) | [GitHub](https://github.com/Cumulus2021/Whitepaper) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [CheersLand Labs](https://cheersland.org/) | Multi-game Platform for Polkadot & Kusama | [GitHub](https://github.com/cheersland) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [UNI-ARTS](https://app.uniarts.network/) | Ruby Substate Client | [GitHub](https://github.com/uni-arts-chain/sr25519) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Skye Kiwi](https://skye.kiwi/) | SkyeKiwi Protocol | [GitHub](https://github.com/skyekiwi) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Evercity](https://evercity.io/) | Sustainable Finance Protocol | [GitHub](https://github.com/EvercityEcosystem) |
  • [ ]
|
  • [x]
|
  • [x]
| - -## :surfing_woman: Wave 12 - Fourth Quarter 2021 +| [Pawn](https://github.com/pawnz0) | NuLink | [GitHub](https://github.com/pawnz0/NuLink) | ☐ | ☒ | ☒ | +| [Cyril Carlier](https://github.com/CrommVardek) | Polk-Auction Website | [GitHub](https://github.com/CrommVardek) | ☐ | ☒ | ☒ | +| [Uddug](https://uddug.com/) | JuniDB - Peer-to-Peer Databases | [GitHub](http://github.com/uddugteam/) | ☐ | ☐ | ☐ | +| [Canyon Labs](https://canyon-network.io) | Permanent decentralized storage Phase 2 | [GitHub](https://github.com/canyon-network) | ☐ | ☒ | ☒ | +| [Skynet Labs](https://siasky.net/) | Pallet for Decentralized Off-Chain Storage on Skynet | [GitHub](https://gitlab.com/SkynetLabs) | ☐ | ☒ | ☒ | +| [Uniwrap/1001 Group](https://uniwrap.io/) | Project 1001 | [GitHub](https://github.com/uniwrap-protocol) | ☐ | ☐ | ☐ | +| [YibanChen](https://yibanchen.com) | Notes DApp & Site-Pallet | [GitHub](https://github.com/YibanChen/) | ☐ | ☒ | ☐ | +| [SuperColony](https://github.com/Supercolony-net) | OpenBrush - Secure smart-contract development on ink! | [GitHub](https://github.com/Supercolony-net) | ☐ | ☒ | ☒ | +| [Banksy Finance](http://www.banksy.finance/) | NFT Pool-Based Lending Hub | [GitHub](https://github.com/Banksy-Finance) | ☐ | ☐ | ☐ | +| [SubDAO Labs](https://www.subdao.network/) | PolkaSign - Web3.0 app for electronic agreements | [GitHub](https://github.com/subdao-network) | ☐ | ☒ | ☒ | +| [Valibre](https://valibre.org) | People Local Interactions Protocol (PLIP) | [GitHub](https://github.com/valibre-org/) | ☐ | ☐ | ☐ | +| [Reaudito](https://shivarthu.reaudito.com/#/) | Shivarthu: A blockchain-based decentralized governance system | [GitHub](https://github.com/amiyatulu/shivarthu) | ☐ | ☒ | ☐ | +| Uniscan | NFT Explorer | [GitHub](https://github.com/wuminzhe) | ☐ | ☒ | ☒ | +| [LimeChain](https://limechain.tech) | Subsembly - Support for GRANDPA | [GitHub](https://github.com/LimeChain) | ☐ | ☐ | ☐ | +| [OpenSquare](https://www.opensquare.network) | Off-chain voting platform | [GitHub](https://github.com/opensquare-network/) | ☐ | ☒ | ☒ | +| [Health Hero](https://www.gohealthhero.com/) | NFT Product Analytics Suite | N/A | ☐ | ☐ | ☐ | +| [Tesseract](https://tesseract.one/) | Mobile dApps/Wallet Connection | [GitHub](https://github.com/tesseract-one) | ☐ | ☒ | ☐ | +| [Wow Labz](http://www.wowlabz.com) | Dot Marketplace | [GitHub](https://github.com/WowLabz) | ☐ | ☒ | ☒ | +| [Perun Network](https://perun.network/) | Perun Channels - Integration with go-perun | [GitHub](https://github.com/perun-network/) | ☐ | ☒ | ☒ | +| [InvArchitects](https://www.invarch.io/) | InvArch - IP Infrastructure for Substrate | [GitHub](https://github.com/InvArch) | ☐ | ☒ | ☒ | +| [SubGame Network](https://subgame.org) | A decentralized game platform Phase 2| [GitHub](https://github.com/SubGame-Network) | ☐ | ☒ | ☒ | +| [CESS LAB](https://www.cess.cloud/) | Cumulus Encrypted Storage System (CESS) | [GitHub](https://github.com/Cumulus2021/Whitepaper) | ☐ | ☒ | ☒ | +| [CheersLand Labs](https://cheersland.org/) | Multi-game Platform for Polkadot & Kusama | [GitHub](https://github.com/cheersland) | ☐ | ☐ | ☐ | +| [UNI-ARTS](https://app.uniarts.network/) | Ruby Substate Client | [GitHub](https://github.com/uni-arts-chain/sr25519) | ☐ | ☒ | ☐ | +| [Skye Kiwi](https://skye.kiwi/) | SkyeKiwi Protocol | [GitHub](https://github.com/skyekiwi) | ☐ | ☒ | ☒ | +| [Evercity](https://evercity.io/) | Sustainable Finance Protocol | [GitHub](https://github.com/EvercityEcosystem) | ☐ | ☒ | ☒ | + +## 🏄‍♀️ Wave 12 - Fourth Quarter 2021 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| Matthew Darnell | cScale | [GitHub](https://github.com/MatthewDarnell/cScale) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Web3go](https://web3go.xyz/) | Web3go | [GitHub](https://github.com/web3go-xyz) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Prosopo Limited](https://prosopo.io) | Prosopo: Human Verification Marketplace | [GitHub](https://github.com/prosopo-io) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Litentry](www.litentry.com) | Polka SignIn | [GitHub](https://github.com/litentry) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [gmajor](https://github.com/gmajor-encrypt) | PHP RPC Lib | [GitHub](https://github.com/gmajor-encrypt/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [logion](https://logion.network/) | Logion wallet | [GitHub](https://github.com/logion-network) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SuperColony](https://www.supercolony.net/) | OpenBrush - Secure smart-contract development on ink! Phase 2 | [GitHub](https://github.com/Supercolony-net) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Nitor Infotech](https://www.nitorinfotech.com/) | Php substrate api | [GitHub](https://github.com/nitor-infotech-oss) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [@agryaznov](https://github.com/agryaznov) | Candle Auctions on Ink! | [GitHub](https://github.com/agryaznov/candle-auction-ink) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Iridium Industries](http://www.iridium.industries) | Iris: Decentralized storage network for substrate-based chains | [GitHub](https://github.com/iridium-labs/iris) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [DICO Team](https://dico.io/) | DICO: Decentralized and governable ICO platform | [GitHub](https://github.com/DICO-TEAM/dico-chain) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [DodoRare, Inc.](https://dodorare.com) | Crossbow - Cross-Platform Rust Toolkit for Games | [GitHub](https://github.com/dodorare) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Rainbowcity Foundation](http://www.rainbowcity.io/) | RainbowDAO Protocol ink! Phase 1 | [GitHub](https://github.com/RainbowcityFoundation/RainbowcityDAO) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Web Registry DAO](www.wika.network) | Wika Network | [GitHub](https://github.com/randombishop/wika_node) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Helikon Labs](http://www.helikon.tech/) | SubVT Telegram Bot for Kusama and Polkadot | [GitHub](https://github.com/helikon-labs/polkadot-kusama-1kv-telegram-bot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Elamin LTD](http://imbue.network/) | Imbue Network | [GitHub](https://github.com/ImbueNetwork) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Koi Metaverse](https://koi.io/) | Building the Digital Collectibles Platform for Virtual GameFi NFTs | [GitHub](https://github.com/KoiMetaverse) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Health Hero](https://www.gohealthhero.com/) | Decentralized Well-being Game API | [GitHub](https://github.com/iumairazhar) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [UNIVERSALDOT FOUNDATION](https://universaldot.foundation) | A freelancing decentralized application | [GitHub](https://github.com/UniversalDot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [AdMeta](https://admeta.network/) | A privacy-preserving Ad Platform | [GitHub](https://github.com/AdMetaNetwork/admeta) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| Crypto Pay Lab (CPL)) | Dotpay a github paid task platform using DOT | [GitHub](https://github.com/bytepayment) |
  • [ ]
|
  • [x]
|
  • [ ]
| +| Matthew Darnell | cScale | [GitHub](https://github.com/MatthewDarnell/cScale) | ☐ | ☒ | ☐ | +| [Web3go](https://web3go.xyz/) | Web3go | [GitHub](https://github.com/web3go-xyz) | ☐ | ☒ | ☐ | +| [Prosopo Limited](https://prosopo.io) | Prosopo: Human Verification Marketplace | [GitHub](https://github.com/prosopo-io) | ☐ | ☒ | ☒ | +| [Litentry](www.litentry.com) | Polka SignIn | [GitHub](https://github.com/litentry) | ☐ | ☐ | ☐ | +| [gmajor](https://github.com/gmajor-encrypt) | PHP RPC Lib | [GitHub](https://github.com/gmajor-encrypt/) | ☐ | ☒ | ☒ | +| [logion](https://logion.network/) | Logion wallet | [GitHub](https://github.com/logion-network) | ☐ | ☒ | ☒ | +| [SuperColony](https://www.supercolony.net/) | OpenBrush - Secure smart-contract development on ink! Phase 2 | [GitHub](https://github.com/Supercolony-net) | ☐ | ☒ | ☐ | +| [Nitor Infotech](https://www.nitorinfotech.com/) | Php substrate api | [GitHub](https://github.com/nitor-infotech-oss) | ☐ | ☒ | ☒ | +| [@agryaznov](https://github.com/agryaznov) | Candle Auctions on Ink! | [GitHub](https://github.com/agryaznov/candle-auction-ink) | ☐ | ☒ | ☒ | +| [Iridium Industries](http://www.iridium.industries) | Iris: Decentralized storage network for substrate-based chains | [GitHub](https://github.com/iridium-labs/iris) | ☐ | ☒ | ☒ | +| [DICO Team](https://dico.io/) | DICO: Decentralized and governable ICO platform | [GitHub](https://github.com/DICO-TEAM/dico-chain) | ☐ | ☐ | ☐ | +| [DodoRare, Inc.](https://dodorare.com) | Crossbow - Cross-Platform Rust Toolkit for Games | [GitHub](https://github.com/dodorare) | ☐ | ☒ | ☒ | +| [Rainbowcity Foundation](http://www.rainbowcity.io/) | RainbowDAO Protocol ink! Phase 1 | [GitHub](https://github.com/RainbowcityFoundation/RainbowcityDAO) | ☐ | ☒ | ☒ | +| [Web Registry DAO](www.wika.network) | Wika Network | [GitHub](https://github.com/randombishop/wika_node) | ☐ | ☒ | ☐ | +| [Helikon Labs](http://www.helikon.tech/) | SubVT Telegram Bot for Kusama and Polkadot | [GitHub](https://github.com/helikon-labs/polkadot-kusama-1kv-telegram-bot) | ☐ | ☒ | ☒ | +| [Elamin LTD](http://imbue.network/) | Imbue Network | [GitHub](https://github.com/ImbueNetwork) | ☐ | ☒ | ☒ | +| [Koi Metaverse](https://koi.io/) | Building the Digital Collectibles Platform for Virtual GameFi NFTs | [GitHub](https://github.com/KoiMetaverse) | ☐ | ☐ | ☐ | +| [Health Hero](https://www.gohealthhero.com/) | Decentralized Well-being Game API | [GitHub](https://github.com/iumairazhar) | ☐ | ☐ | ☐ | +| [UNIVERSALDOT FOUNDATION](https://universaldot.foundation) | A freelancing decentralized application | [GitHub](https://github.com/UniversalDot) | ☐ | ☒ | ☒ | +| [AdMeta](https://admeta.network/) | A privacy-preserving Ad Platform | [GitHub](https://github.com/AdMetaNetwork/admeta) | ☐ | ☐ | ☐ | +| Crypto Pay Lab (CPL)) | Dotpay a github paid task platform using DOT | [GitHub](https://github.com/bytepayment) | ☐ | ☒ | ☐ | # 2022 -## :surfing_woman: Wave 13 - First Quarter 2022 +## 🏄‍♀️ Wave 13 - First Quarter 2022 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [Chainify](https://github.com/chainify) | Nolik | [GitHub](https://github.com/chainify) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Pennsylvania State University](https://www.psu.edu/) | Avoiding Rust Deadlocks via Lifetime Visualization | [GitHub](https://songlh.github.io/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Anagolay](https://anagolay.network/) | Project Idiyanale | [GitHub](https://github.com/anagolay) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Fennel Labs](https://fennellabs.com/) | Fennel Protocol | [GitHub](https://github.com/fennelLabs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Valletech AB](https://valletech.eu/) | Polkawatch | [GitHub](https://gitlab.com/polkawatch) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [EzCode](https://ezcode.co/) | Polkadot.js NoCode Plugin | [GitHub](https://github.com/inartin) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Virto Network](https://virto.network/) | LIP payments pallet | [GitHub](https://github.com/virto-network/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Kami Ekbatanifard](https://github.com/Nick-1979/) | Polkadot.js Plus Extension | [GitHub](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Dora Factory](https://dorafactory.org/) | Multisig UI | [GitHub](https://github.com/DoraFactory) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Blackprint](https://github.com/Blackprint) | Integrating Polkadot.js with Blackprint | [GitHub](https://github.com/Blackprint) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [OpenSquare Network](https://www.opensquare.network/) | OpenSquare Paid QA protocol | [GitHub](https://github.com/opensquare-network/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [@Scale Technologies](https://atscale.xyz) | Libra - Decentralized Payment Network | [GitHub](https://github.com/atscaletech/) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Interstellar](https://www.interstellar.gg/) | Interstellar - Wallet Phase 1 | [GitHub](https://github.com/Interstellar-Network) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Pendulum](https://pendulumchain.org/) | Spacewalk: a Stellar bridge | [GitHub](https://github.com/pendulum-chain) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Dmitrii Koshelev](https://github.com/dishport) | Implementation of the new hash function to BLS12 curves | [GitHub](https://github.com/dishport) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Hamster](https://github.com/orgs/hamster-shared) | Hamster - A decentralized computing network | [GitHub](https://github.com/orgs/hamster-shared) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Papers GmbH](https://papers.ch/en/) | Zaturn - A Generic Attestable Oracle parachain Phase 1 | [GitHub](https://github.com/airgap-it) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Slonigiraf](https://www.slonigiraf.org/) | SLON - a recommendation letter system| [GitHub](https://github.com/slonigiraf) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Helixstreet](https://helixstreet.io/) | Helixstreet Module | [GitHub](https://github.com/helixstreet) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Cryptoviet](https://team.cryptoviet.com/) | Gafi Network - The Network of Game Finance | [GitHub](https://github.com/cryptoviet/gafi) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Asylum](https://asylum.space/) | Metaverse for next generation gaming | [GitHub](https://gitlab.com/asylum-space/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [CESS LAB](https://www.cess.cloud/) | Data Store Pallet | [GitHub](https://github.com/CESSProject/cess) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ChainSafe](https://chainsafe.io/) | Substrate Core Polywrapper | [GitHub](https://github.com/polywrap) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Bela Supernova](https://bsn.si/en/home/) | On-chain cash exchange (OCEX) | |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Second State](https://www.secondstate.io/) | WasmEdge for Substrate | [GitHub](https://github.com/wasmedge) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Wow Labz](https://www.wowlabz.com/) | Dot Marketplace Phase 2 | [GitHub](https://github.com/WowLabz) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Stardust Labs Inc.](https://stardust.finance/) | Uncollateralized Stablecoin Research and Design | [GitHub](https://github.com/adit313/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Hashed Systems](https://hashed.io) | Native Bitcoin Vaults (NBV) | [GitHub](https://github.com/hashed-io) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Setheum](https://setheum.xyz/) | Setheum HighEnd LaunchPad Crowdsales Module | [GitHub](https://github.com/Setheum-Labs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [SaaS3 Lab](https://www.saas3.io) | SaaS3 | [GitHub](https://github.com/SaaS3Lab) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [NUTS Finance](https://nuts.finance) | DOT-pegged derivative built on top of the stable asset protocol | [GitHub](https://github.com/nutsfinance/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Strategy Object](https://strategyobject.com/) | Substrate Client for Java | [GitHub](https://github.com/strategyobject/substrate-client-java) |
  • [ ]
|
  • [x]
|
  • [ ]
| - -## :surfing_woman: Wave 14 - Second Quarter 2022 +| [Chainify](https://github.com/chainify) | Nolik | [GitHub](https://github.com/chainify) | ☐ | ☒ | ☒ | +| [Pennsylvania State University](https://www.psu.edu/) | Avoiding Rust Deadlocks via Lifetime Visualization | [GitHub](https://songlh.github.io/) | ☐ | ☒ | ☒ | +| [Anagolay](https://anagolay.network/) | Project Idiyanale | [GitHub](https://github.com/anagolay) | ☐ | ☒ | ☒ | +| [Fennel Labs](https://fennellabs.com/) | Fennel Protocol | [GitHub](https://github.com/fennelLabs) | ☐ | ☒ | ☒ | +| [Valletech AB](https://valletech.eu/) | Polkawatch | [GitHub](https://gitlab.com/polkawatch) | ☐ | ☒ | ☒ | +| [EzCode](https://ezcode.co/) | Polkadot.js NoCode Plugin | [GitHub](https://github.com/inartin) | ☐ | ☒ | ☒ | +| [Virto Network](https://virto.network/) | LIP payments pallet | [GitHub](https://github.com/virto-network/) | ☐ | ☒ | ☒ | +| [Kami Ekbatanifard](https://github.com/Nick-1979/) | Polkadot.js Plus Extension | [GitHub](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki) | ☐ | ☒ | ☒ | +| [Dora Factory](https://dorafactory.org/) | Multisig UI | [GitHub](https://github.com/DoraFactory) | ☐ | ☒ | ☒ | +| [Blackprint](https://github.com/Blackprint) | Integrating Polkadot.js with Blackprint | [GitHub](https://github.com/Blackprint) | ☐ | ☒ | ☒ | +| [OpenSquare Network](https://www.opensquare.network/) | OpenSquare Paid QA protocol | [GitHub](https://github.com/opensquare-network/) | ☐ | ☒ | ☒ | +| [@Scale Technologies](https://atscale.xyz) | Libra - Decentralized Payment Network | [GitHub](https://github.com/atscaletech/) | ☐ | ☒ | ☐ | +| [Interstellar](https://www.interstellar.gg/) | Interstellar - Wallet Phase 1 | [GitHub](https://github.com/Interstellar-Network) | ☐ | ☒ | ☐ | +| [Pendulum](https://pendulumchain.org/) | Spacewalk: a Stellar bridge | [GitHub](https://github.com/pendulum-chain) | ☐ | ☒ | ☐ | +| [Dmitrii Koshelev](https://github.com/dishport) | Implementation of the new hash function to BLS12 curves | [GitHub](https://github.com/dishport) | ☐ | ☒ | ☐ | +| [Hamster](https://github.com/orgs/hamster-shared) | Hamster - A decentralized computing network | [GitHub](https://github.com/orgs/hamster-shared) | ☐ | ☒ | ☒ | +| [Papers GmbH](https://papers.ch/en/) | Zaturn - A Generic Attestable Oracle parachain Phase 1 | [GitHub](https://github.com/airgap-it) | ☐ | ☐ | ☐ | +| [Slonigiraf](https://www.slonigiraf.org/) | SLON - a recommendation letter system| [GitHub](https://github.com/slonigiraf) | ☐ | ☒ | ☒ | +| [Helixstreet](https://helixstreet.io/) | Helixstreet Module | [GitHub](https://github.com/helixstreet) | ☐ | ☐ | ☐ | +| [Cryptoviet](https://team.cryptoviet.com/) | Gafi Network - The Network of Game Finance | [GitHub](https://github.com/cryptoviet/gafi) | ☐ | ☒ | ☐ | +| [Asylum](https://asylum.space/) | Metaverse for next generation gaming | [GitHub](https://gitlab.com/asylum-space/) | ☐ | ☒ | ☒ | +| [CESS LAB](https://www.cess.cloud/) | Data Store Pallet | [GitHub](https://github.com/CESSProject/cess) | ☐ | ☒ | ☒ | +| [ChainSafe](https://chainsafe.io/) | Substrate Core Polywrapper | [GitHub](https://github.com/polywrap) | ☐ | ☐ | ☐ | +| [Bela Supernova](https://bsn.si/en/home/) | On-chain cash exchange (OCEX) | N/A | ☐ | ☒ | ☒ | +| [Second State](https://www.secondstate.io/) | WasmEdge for Substrate | [GitHub](https://github.com/wasmedge) | ☐ | ☒ | ☐ | +| [Wow Labz](https://www.wowlabz.com/) | Dot Marketplace Phase 2 | [GitHub](https://github.com/WowLabz) | ☐ | ☒ | ☒ | +| [Stardust Labs Inc.](https://stardust.finance/) | Uncollateralized Stablecoin Research and Design | [GitHub](https://github.com/adit313/) | ☐ | ☒ | ☒ | +| [Hashed Systems](https://hashed.io) | Native Bitcoin Vaults (NBV) | [GitHub](https://github.com/hashed-io) | ☐ | ☒ | ☒ | +| [Setheum](https://setheum.xyz/) | Setheum HighEnd LaunchPad Crowdsales Module | [GitHub](https://github.com/Setheum-Labs) | ☐ | ☐ | ☐ | +| [SaaS3 Lab](https://www.saas3.io) | SaaS3 | [GitHub](https://github.com/SaaS3Lab) | ☐ | ☐ | ☐ | +| [NUTS Finance](https://nuts.finance) | DOT-pegged derivative built on top of the stable asset protocol | [GitHub](https://github.com/nutsfinance/) | ☐ | ☒ | ☒ | +| [Strategy Object](https://strategyobject.com/) | Substrate Client for Java | [GitHub](https://github.com/strategyobject/substrate-client-java) | ☐ | ☒ | ☐ | + +## 🏄‍♀️ Wave 14 - Second Quarter 2022 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [TDSoftware](https://www.tdsoftware.de/) | SubIdentity | [GitHub](https://github.com/TDSoftware) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ChainSafe Systems](https://chainsafe.io/) | SubstrateSnap Maintenance Proposal | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [HugoByte](https://hugobyte.com/) | Project Aurras - MVP - Phase 2 | [GitHub](https://github.com/HugoByte) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Perun Network](https://perun.network/) | Perun App Channels | [GitHub](https://github.com/perun-network/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [ChainSafe Systems](https://chainsafe.io/) | Privacy enhancement for Polkadot-js extension | [GitHub](https://github.com/ChainSafe) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [BQP](https://qbitcoin.tech/) | Quantum Lock for QBITCOIN | [GitHub](https://github.com/bqpquantum/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Simply VC](https://simply-vc.com.mt/) | PANIC Monitoring and Alerting For Blockchains | [GitHub](https://github.com/SimplyVC/panic) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Artree LLC](https://artree.co.jp/) | Zero Network | [GitHub](https://github.com/zero-network) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [sigma prime](https://sigmaprime.io/) | Differential Fuzzer | [GitHub](https://github.com/sigp) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [t3rn](https://www.t3rn.io/) | XBI - xcm-based high-level standard and interface (ABI) for smart contracts | [GitHub](https://github.com/t3rn/t3rn) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Dante Network](https://www.dantechain.com/) | Dante Network | [GitHub](https://github.com/dantenetwork) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Verida](https://www.verida.io/) | Single Sign-On for Apps | [GitHub](https://github.com/verida) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Kami Ekbatanifard](https://github.com/Nick-1979/) | Polkadot js plus / Nomination pools | [GitHub](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Afloat Inc](https://stayafloat.io/#/) | Tax Infrastructure Polkadot Integration | N/A |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [gmajor](https://github.com/gmajor-encrypt) | SCALE Codec Comparator | [GitHub](https://github.com/gmajor-encrypt) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Rusty Crewmates](http://rustycrewmates.com/) | Substrate Tutorials | [GitHub](https://github.com/rusty-crewmates/substrate-tutorials) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Sequester](https://github.com/SequesterChain) | A Common-Good Carbon Sink on Polkadot | [GitHub](https://github.com/SequesterChain/pallets) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Keysafe Network](https://github.com/keysafe-protocol) | A decentralized protocol for private key custody and crypto asset management | [GitHub](https://github.com/keysafe-protocol) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Fennel Labs](https://fennellabs.com/) | Whiteflag on Fennel Protocol | [GitHub](https://github.com/fennelLabs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Relationlabs](https://relationlabs.ai/#/home) | Relation Graph | [GitHub](https://github.com/relationlabs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Decentration](https://kabocha.network) | Supersig | [GitHub](https://github.com/kabocha-network) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Web3 Labs Ltd](https://www.web3labs.com/epirus-explorer) | Epirus Substrate Explorer | [GitHub](https://github.com/web3labs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [SuperColony](https://github.com/Supercolony-net) | Sol2Ink | [GitHub](https://github.com/Supercolony-net) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [SuperColony](https://github.com/Supercolony-net) | OpenBrush Phase 3 | [GitHub](https://github.com/Supercolony-net) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [FS](https://fair-squares.nl/) | Fair Squares | [GitHub](https://github.com/Fair-squares) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Ideal Labs](https://www.idealabs.network/) | Iris: Phase 2 | [GitHub](https://github.com/ideal-lab5) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [NeoPower](https://www.neopower.digital/) | Roloi: Stream money from one wallet to another | [GitHub](https://github.com/RoloiMoney) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Tribal Protocol Labs](https://www.tribal.fyi/) | Tribal Protocol Smart Contract Development | [GitHub](https://github.com/tribal-protocol) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Yahuang Wu](https://github.com/wuyahuang) | Dual-Key Stealth Address Protocol | [GitHub](https://github.com/wuyahuang) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [UNIVERSALDOT FOUNDATION](https://universaldot.foundation) | Universaldot.me Phase 2 | [GitHub](https://github.com/UniversalDot) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [Societal Labs Ltd.](https://www.sctl.xyz/) | Societal - MVP - Phase 1 | [GitHub](https://github.com/sctllabs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Faceless Protocol](https://github.com/HeisenbergLin22) | Faceless Protocol | [GitHub](https://github.com/HeisenbergLin22) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [SuperColony](https://github.com/Supercolony-net) | Typechain | [GitHub](https://github.com/Supercolony-net/typechain-polkadot) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Codelight](https://massbit.io/) | Massbit Route | [GitHub](https://github.com/massbitprotocol/massbitroute) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Hypha Hashed Partners](https://hypha.earth/) | Social Recovery Wallet | [GitHub](https://github.com/hypha-dao) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [MangoBOX labs](http://mangobox.xyz/) | MangoBOX Protocol | [GitHub](https://github.com/Mangoboxlabs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| - -## :surfing_woman: Wave 15 - Third Quarter 2022 +| [TDSoftware](https://www.tdsoftware.de/) | SubIdentity | [GitHub](https://github.com/TDSoftware) | ☐ | ☒ | ☒ | +| [ChainSafe Systems](https://chainsafe.io/) | SubstrateSnap Maintenance Proposal | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☒ | ☒ | +| [HugoByte](https://hugobyte.com/) | Project Aurras - MVP - Phase 2 | [GitHub](https://github.com/HugoByte) | ☐ | ☐ | ☐ | +| [Perun Network](https://perun.network/) | Perun App Channels | [GitHub](https://github.com/perun-network/) | ☐ | ☒ | ☒ | +| [ChainSafe Systems](https://chainsafe.io/) | Privacy enhancement for Polkadot-js extension | [GitHub](https://github.com/ChainSafe) | ☐ | ☒ | ☒ | +| [BQP](https://qbitcoin.tech/) | Quantum Lock for QBITCOIN | [GitHub](https://github.com/bqpquantum/) | ☐ | ☐ | ☐ | +| [Simply VC](https://simply-vc.com.mt/) | PANIC Monitoring and Alerting For Blockchains | [GitHub](https://github.com/SimplyVC/panic) | ☐ | ☒ | ☒ | +| [Artree LLC](https://artree.co.jp/) | Zero Network | [GitHub](https://github.com/zero-network) | ☐ | ☐ | ☐ | +| [sigma prime](https://sigmaprime.io/) | Differential Fuzzer | [GitHub](https://github.com/sigp) | ☐ | ☐ | ☐ | +| [t3rn](https://www.t3rn.io/) | XBI - xcm-based high-level standard and interface (ABI) for smart contracts | [GitHub](https://github.com/t3rn/t3rn) | ☐ | ☒ | ☒ | +| [Dante Network](https://www.dantechain.com/) | Dante Network | [GitHub](https://github.com/dantenetwork) | ☐ | ☒ | ☐ | +| [Verida](https://www.verida.io/) | Single Sign-On for Apps | [GitHub](https://github.com/verida) | ☐ | ☐ | ☐ | +| [Kami Ekbatanifard](https://github.com/Nick-1979/) | Polkadot js plus / Nomination pools | [GitHub](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki) | ☐ | ☒ | ☒ | +| [Afloat Inc](https://stayafloat.io/#/) | Tax Infrastructure Polkadot Integration | N/A | ☐ | ☒ | ☐ | +| [gmajor](https://github.com/gmajor-encrypt) | SCALE Codec Comparator | [GitHub](https://github.com/gmajor-encrypt) | ☐ | ☒ | ☐ | +| [Rusty Crewmates](http://rustycrewmates.com/) | Substrate Tutorials | [GitHub](https://github.com/rusty-crewmates/substrate-tutorials) | ☐ | ☒ | ☐ | +| [Sequester](https://github.com/SequesterChain) | A Common-Good Carbon Sink on Polkadot | [GitHub](https://github.com/SequesterChain/pallets) | ☐ | ☒ | ☒ | +| [Keysafe Network](https://github.com/keysafe-protocol) | A decentralized protocol for private key custody and crypto asset management | [GitHub](https://github.com/keysafe-protocol) | ☐ | ☐ | ☐ | +| [Fennel Labs](https://fennellabs.com/) | Whiteflag on Fennel Protocol | [GitHub](https://github.com/fennelLabs) | ☐ | ☒ | ☒ | +| [Relationlabs](https://relationlabs.ai/#/home) | Relation Graph | [GitHub](https://github.com/relationlabs) | ☐ | ☐ | ☐ | +| [Decentration](https://kabocha.network) | Supersig | [GitHub](https://github.com/kabocha-network) | ☐ | ☒ | ☐ | +| [Web3 Labs Ltd](https://www.web3labs.com/epirus-explorer) | Epirus Substrate Explorer | [GitHub](https://github.com/web3labs) | ☐ | ☒ | ☒ | +| [SuperColony](https://github.com/Supercolony-net) | Sol2Ink | [GitHub](https://github.com/Supercolony-net) | ☐ | ☐ | ☐ | +| [SuperColony](https://github.com/Supercolony-net) | OpenBrush Phase 3 | [GitHub](https://github.com/Supercolony-net) | ☐ | ☒ | ☐ | +| [FS](https://fair-squares.nl/) | Fair Squares | [GitHub](https://github.com/Fair-squares) | ☐ | ☒ | ☐ | +| [Ideal Labs](https://www.idealabs.network/) | Iris: Phase 2 | [GitHub](https://github.com/ideal-lab5) | ☐ | ☒ | ☐ | +| [NeoPower](https://www.neopower.digital/) | Roloi: Stream money from one wallet to another | [GitHub](https://github.com/RoloiMoney) | ☐ | ☒ | ☒ | +| [Tribal Protocol Labs](https://www.tribal.fyi/) | Tribal Protocol Smart Contract Development | [GitHub](https://github.com/tribal-protocol) | ☐ | ☒ | ☐ | +| [Yahuang Wu](https://github.com/wuyahuang) | Dual-Key Stealth Address Protocol | [GitHub](https://github.com/wuyahuang) | ☐ | ☒ | ☒ | +| [UNIVERSALDOT FOUNDATION](https://universaldot.foundation) | Universaldot.me Phase 2 | [GitHub](https://github.com/UniversalDot) | ☒ | ☐ | ☐ | +| [Societal Labs Ltd.](https://www.sctl.xyz/) | Societal - MVP - Phase 1 | [GitHub](https://github.com/sctllabs) | ☐ | ☐ | ☐ | +| [Faceless Protocol](https://github.com/HeisenbergLin22) | Faceless Protocol | [GitHub](https://github.com/HeisenbergLin22) | ☐ | ☒ | ☐ | +| [SuperColony](https://github.com/Supercolony-net) | Typechain | [GitHub](https://github.com/Supercolony-net/typechain-polkadot) | ☐ | ☒ | ☒ | +| [Codelight](https://massbit.io/) | Massbit Route | [GitHub](https://github.com/massbitprotocol/massbitroute) | ☐ | ☒ | ☐ | +| [Hypha Hashed Partners](https://hypha.earth/) | Social Recovery Wallet | [GitHub](https://github.com/hypha-dao) | ☐ | ☒ | ☐ | +| [MangoBOX labs](http://mangobox.xyz/) | MangoBOX Protocol | [GitHub](https://github.com/Mangoboxlabs) | ☐ | ☐ | ☐ | + +## 🏄‍♀️ Wave 15 - Third Quarter 2022 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [QRUCIAL OÜ](https://qrucial.io/) | QRUCIAL DAO | [GitHub](https://github.com/Qrucial/QRUCIAL-DAO) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Polkadot js plus](http://polkadotjs.plus/) | Polkadot js plus / Social Recovery Wallet | [GitHub](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Lee](https://github.com/rust-0x0) | Hex Space Social Graph | [GitHub](https://github.com/rust-0x0) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Liberland LLC](https://liberland.org/en/) | Liberland Pallets | [GitHub](https://github.com/liberland/liberland_substrate) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Standard Protocol](https://standard.tech/) | Signac - a monorepo plugin for developing multiple Parity ink! smart contracts | [GitHub](https://github.com/standardweb3/signac) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [B-Datagray](https://www.b-datagray.com/) | Datagen Project | [GitHub](https://github.com/Datagen-Project) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Colorful Notion](https://polkaholic.io/#chains) | Polkaholic.io's Multi-Chain Substrate Block Explorer | [GitHub](https://github.com/colorfulnotion/polkaholic/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Common Orbit LLC](https://brson.github.io) | `wasm-opt` for Rust | [GitHub](https://github.com/brson/wasm-opt-rs) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Blockcoders](https://blockcoders.io/) | Ink Explorer | [GitHub](https://github.com/blockcoders) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Equilibrium](https://equilibrium.co/) | Polkadot Light Client in C++ | [GitHub](https://github.com/eqlabs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Open rollup](https://github.com/openrollup-zk) | Open rollup - MVP - Phase 1 | [GitHub](https://github.com/openrollup-zk) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Veridise](https://veridise.com/) | Vanguard | [GitHub](https://github.com/Veridise/Vanguard) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Karolis Ramanauskas](https://krl.is/) | Generic Sybil-Resistant Faucet | [GitHub](https://github.com/karooolis) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [LimeChain](https://limechain.tech/) | Research feasibility for a Go Runtime | [GitHub](https://github.com/LimeChain) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Jim Yam](https://github.com/JimYam) | daos | [GitHub](https://github.com/daos-org/daos.git) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Green Lemon](https://github.com/GreenLemonProtocol) | Green Lemon Protocol | [GitHub](https://github.com/GreenLemonProtocol) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Stardust Labs Inc.](https://stardust.finance/) | Integrating ISO-8583 | [GitHub](https://github.com/adit313/) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [TwinP](https://www.linkedin.com/in/elioprifti/) | Escrow Pallet | [GitHub](https://github.com/herou) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Meta Defender Team](https://github.com/Meta-Defender/) | Meta Defender | [GitHub](https://github.com/Meta-Defender/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [ParaSpell](https://github.com/paraspell) | ParaSpell | [GitHub](https://github.com/paraspell) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Primis Labs](https://github.com/Primis-Labs) | Primis | [GitHub](https://github.com/Primis-Labs/client) |
  • [ ]
|
  • [x]
|
  • [x]
| -| [Uke](https://github.com/Uke-Messaging) | Uke Messaging - PoC - Phase 1 | [GitHub](https://github.com/Uke-Messaging) |
  • [x]
|
  • [ ]
|
  • [ ]
| -| [Redstone Network](https://github.com/difttt) | Redstone Network | [GitHub](https://github.com/difttt) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [JURIMETRIC TECNOLOGIA LTDA](https://www.jurimetric.com.br/) | Polkadart | [GitHub](https://github.com/rankanizer/polkadart) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Skye Kiwi](https://skye.kiwi/) | Choko Wallet | [GitHub](https://github.com/skyekiwi) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Popular Coding](https://www.popularcoding.com/) | Ventur | [GitHub](https://github.com/popular_coding) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Asylum](https://asylum.space/) | Asylum follow-up 1 | [GitHub](https://gitlab.com/asylum-space/) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [Cyril Carlier](https://github.com/CrommVardek) | Maki| [GitHub](https://github.com/CrommVardek) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [TopMonks](https://www.topmonks.com/) | Calamar| [GitHub](https://github.com/topmonks/calamar) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Bela Supernova](https://bsn.si/) | Rubeus Keeper| [GitHub](https://github.com/bsn-si) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Web3 Labs Ltd](https://www.web3labs.com/epirus-explorer) | Epirus Substrate Explorer - Phase 2 | [GitHub](https://github.com/web3labs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Uke](https://github.com/Uke-Messaging) | Uke Protocol PoC & App (revised) | [GitHub](https://github.com/Uke-Messaging) |
  • [ ]
|
  • [x]
|
  • [ ]
| -| [SuperColony](https://github.com/Supercolony-net) | Typechain Phase 2 | [GitHub](https://github.com/Supercolony-net/typechain-polkadot) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [QSTN](https://qstn.us/) | QSTN | [GitHub](https://github.com/qstnus) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [CESS LAB](https://www.cess.cloud/) | Substats (The framework of lightweight block explorer) | [GitHub](https://github.com/CESSProject) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Polket](https://toearn.fun) | ToEarnFun | [GitHub](https://github.com/polketio/polket-node) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| ALPHA LABS | Binary merkle tree | [GitHub](https://github.com/frisitano) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Standard Protocol](https://standard.tech/) | New Order - a full onchain orderbook dex with indexers | [GitHub](https://github.com/standardweb3) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [hack-ink](https://github.com/hack-ink) | Subalfred | [GitHub](https://github.com/hack-ink/subalfred) |
  • [ ]
|
  • [ ]
|
  • [ ]
| - -## :surfing_woman: Wave 16 - Fourth Quarter 2022 +| [QRUCIAL OÜ](https://qrucial.io/) | QRUCIAL DAO | [GitHub](https://github.com/Qrucial/QRUCIAL-DAO) | ☐ | ☐ | ☐ | +| [Polkadot js plus](http://polkadotjs.plus/) | Polkadot js plus / Social Recovery Wallet | [GitHub](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki) | ☐ | ☒ | ☐ | +| [Lee](https://github.com/rust-0x0) | Hex Space Social Graph | [GitHub](https://github.com/rust-0x0) | ☐ | ☒ | ☐ | +| [Liberland LLC](https://liberland.org/en/) | Liberland Pallets | [GitHub](https://github.com/liberland/liberland_substrate) | ☐ | ☐ | ☐ | +| [Standard Protocol](https://standard.tech/) | Signac - a monorepo plugin for developing multiple Parity ink! smart contracts | [GitHub](https://github.com/standardweb3/signac) | ☐ | ☒ | ☒ | +| [B-Datagray](https://www.b-datagray.com/) | Datagen Project | [GitHub](https://github.com/Datagen-Project) | ☐ | ☐ | ☐ | +| [Colorful Notion](https://polkaholic.io/#chains) | Polkaholic.io's Multi-Chain Substrate Block Explorer | [GitHub](https://github.com/colorfulnotion/polkaholic/) | ☐ | ☐ | ☐ | +| [Common Orbit LLC](https://brson.github.io) | `wasm-opt` for Rust | [GitHub](https://github.com/brson/wasm-opt-rs) | ☐ | ☒ | ☒ | +| [Blockcoders](https://blockcoders.io/) | Ink Explorer | [GitHub](https://github.com/blockcoders) | ☐ | ☒ | ☐ | +| [Equilibrium](https://equilibrium.co/) | Polkadot Light Client in C++ | [GitHub](https://github.com/eqlabs) | ☐ | ☐ | ☐ | +| [Open rollup](https://github.com/openrollup-zk) | Open rollup - MVP - Phase 1 | [GitHub](https://github.com/openrollup-zk) | ☐ | ☐ | ☐ | +| [Veridise](https://veridise.com/) | Vanguard | [GitHub](https://github.com/Veridise/Vanguard) | ☐ | ☐ | ☐ | +| [Karolis Ramanauskas](https://krl.is/) | Generic Sybil-Resistant Faucet | [GitHub](https://github.com/karooolis) | ☐ | ☒ | ☒ | +| [LimeChain](https://limechain.tech/) | Research feasibility for a Go Runtime | [GitHub](https://github.com/LimeChain) | ☐ | ☒ | ☒ | +| [Jim Yam](https://github.com/JimYam) | daos | [GitHub](https://github.com/daos-org/daos.git) | ☐ | ☐ | ☐ | +| [Green Lemon](https://github.com/GreenLemonProtocol) | Green Lemon Protocol | [GitHub](https://github.com/GreenLemonProtocol) | ☐ | ☒ | ☐ | +| [Stardust Labs Inc.](https://stardust.finance/) | Integrating ISO-8583 | [GitHub](https://github.com/adit313/) | ☐ | ☒ | ☒ | +| [TwinP](https://www.linkedin.com/in/elioprifti/) | Escrow Pallet | [GitHub](https://github.com/herou) | ☐ | ☒ | ☒ | +| [Meta Defender Team](https://github.com/Meta-Defender/) | Meta Defender | [GitHub](https://github.com/Meta-Defender/) | ☐ | ☐ | ☐ | +| [ParaSpell](https://github.com/paraspell) | ParaSpell | [GitHub](https://github.com/paraspell) | ☐ | ☒ | ☒ | +| [Primis Labs](https://github.com/Primis-Labs) | Primis | [GitHub](https://github.com/Primis-Labs/client) | ☐ | ☒ | ☒ | +| [Uke](https://github.com/Uke-Messaging) | Uke Messaging - PoC - Phase 1 | [GitHub](https://github.com/Uke-Messaging) | ☒ | ☐ | ☐ | +| [Redstone Network](https://github.com/difttt) | Redstone Network | [GitHub](https://github.com/difttt) | ☐ | ☐ | ☐ | +| [JURIMETRIC TECNOLOGIA LTDA](https://www.jurimetric.com.br/) | Polkadart | [GitHub](https://github.com/rankanizer/polkadart) | ☐ | ☐ | ☐ | +| [Skye Kiwi](https://skye.kiwi/) | Choko Wallet | [GitHub](https://github.com/skyekiwi) | ☐ | ☐ | ☐ | +| [Popular Coding](https://www.popularcoding.com/) | Ventur | [GitHub](https://github.com/popular_coding) | ☐ | ☒ | ☐ | +| [Asylum](https://asylum.space/) | Asylum follow-up 1 | [GitHub](https://gitlab.com/asylum-space/) | ☐ | ☒ | ☐ | +| [Cyril Carlier](https://github.com/CrommVardek) | Maki| [GitHub](https://github.com/CrommVardek) | ☐ | ☐ | ☐ | +| [TopMonks](https://www.topmonks.com/) | Calamar| [GitHub](https://github.com/topmonks/calamar) | ☐ | ☐ | ☐ | +| [Bela Supernova](https://bsn.si/) | Rubeus Keeper| [GitHub](https://github.com/bsn-si) | ☐ | ☐ | ☐ | +| [Web3 Labs Ltd](https://www.web3labs.com/epirus-explorer) | Epirus Substrate Explorer - Phase 2 | [GitHub](https://github.com/web3labs) | ☐ | ☐ | ☐ | +| [Uke](https://github.com/Uke-Messaging) | Uke Protocol PoC & App (revised) | [GitHub](https://github.com/Uke-Messaging) | ☐ | ☒ | ☐ | +| [SuperColony](https://github.com/Supercolony-net) | Typechain Phase 2 | [GitHub](https://github.com/Supercolony-net/typechain-polkadot) | ☐ | ☐ | ☐ | +| [QSTN](https://qstn.us/) | QSTN | [GitHub](https://github.com/qstnus) | ☐ | ☐ | ☐ | +| [CESS LAB](https://www.cess.cloud/) | Substats (The framework of lightweight block explorer) | [GitHub](https://github.com/CESSProject) | ☐ | ☐ | ☐ | +| [Polket](https://toearn.fun) | ToEarnFun | [GitHub](https://github.com/polketio/polket-node) | ☐ | ☐ | ☐ | +| ALPHA LABS | Binary merkle tree | [GitHub](https://github.com/frisitano) | ☐ | ☐ | ☐ | +| [Standard Protocol](https://standard.tech/) | New Order - a full onchain orderbook dex with indexers | [GitHub](https://github.com/standardweb3) | ☐ | ☐ | ☐ | +| [hack-ink](https://github.com/hack-ink) | Subalfred | [GitHub](https://github.com/hack-ink/subalfred) | ☐ | ☐ | ☐ | + +## 🏄‍♀️ Wave 16 - Fourth Quarter 2022 | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [CrossChain Labs](https://github.com/CrossChainLabs) | DotPulse | [GitHub](https://github.com/CrossChainLabs) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Jett Hays](https://github.com/jettblu) | Distributed Key Management | [GitHub](https://github.com/KryptikApp) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [NexToken Technology](https://github.com/NexTokenTech) | TREX - Timed Release Encryption Xing chains | [GitHub](https://github.com/NexTokenTech/TREX) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Blockcoders](http://blockcoders.io/) | Cross-Consensus Messaging Software Development Kit | [GitHub](https://github.com/blockcoders) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Keystone Wallet](https://keyst.one/) | Polkadot Snap | [GitHub](https://github.com/KeystoneHQ) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [LeetCoin](https://www.leetcoin.co/) | LeetCoin | [GitHub](https://github.com/nashhq/leetcoin) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [727.ventures](https://github.com/727-Ventures) | Sol2Ink Phase 2 | [GitHub](https://github.com/727-Ventures) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [walt.id](https://walt.id/) | NFT infrastructure | [GitHub](https://github.com/walt-id) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [SydTek](https://sydtek.ai/) | Digital Inheritance in Web3: A Case Study of Soulbound Tokens and Social Recovery Pallets | N/A |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Anagolay](https://anagolay.network/) | Multi-token community contributions for verified creators | [GitHub](https://github.com/anagolay) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Ink Contracts Wizard Team](https://github.com/amankumar1008/contracts-wizard) | Ink Smart Contract Wizard | [GitHub](https://github.com/amankumar1008/contracts-wizard) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [TDSoftware](https://www.tdsoftware.de/) | Substrate IPFS Utilities | [GitHub](https://github.com/TDSoftware) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [Ink Boxes Team](https://github.com/nerdsince98) | Ink Boxes | [GitHub](https://gitlab.com/nerdsince98/learning-ink/) |
  • [ ]
|
  • [ ]
|
  • [ ]
| -| [ParaSpell](https://github.com/paraspell) | ParaSpell Phase 2 | [GitHub](https://github.com/paraspell) |
  • [ ]
|
  • [ ]
|
  • [ ]
| +| [CrossChain Labs](https://github.com/CrossChainLabs) | DotPulse | [GitHub](https://github.com/CrossChainLabs) | ☐ | ☐ | ☐ | +| [Jett Hays](https://github.com/jettblu) | Distributed Key Management | [GitHub](https://github.com/KryptikApp) | ☐ | ☐ | ☐ | +| [NexToken Technology](https://github.com/NexTokenTech) | TREX - Timed Release Encryption Xing chains | [GitHub](https://github.com/NexTokenTech/TREX) | ☐ | ☐ | ☐ | +| [Blockcoders](http://blockcoders.io/) | Cross-Consensus Messaging Software Development Kit | [GitHub](https://github.com/blockcoders) | ☐ | ☐ | ☐ | +| [Keystone Wallet](https://keyst.one/) | Polkadot Snap | [GitHub](https://github.com/KeystoneHQ) | ☐ | ☐ | ☐ | +| [LeetCoin](https://www.leetcoin.co/) | LeetCoin | [GitHub](https://github.com/nashhq/leetcoin) | ☐ | ☐ | ☐ | +| [727.ventures](https://github.com/727-Ventures) | Sol2Ink Phase 2 | [GitHub](https://github.com/727-Ventures) | ☐ | ☐ | ☐ | +| [walt.id](https://walt.id/) | NFT infrastructure | [GitHub](https://github.com/walt-id) | ☐ | ☐ | ☐ | +| [SydTek](https://sydtek.ai/) | Digital Inheritance in Web3: A Case Study of Soulbound Tokens and Social Recovery Pallets | N/A | ☐ | ☐ | ☐ | +| [Anagolay](https://anagolay.network/) | Multi-token community contributions for verified creators | [GitHub](https://github.com/anagolay) | ☐ | ☐ | ☐ | +| [Ink Contracts Wizard Team](https://github.com/amankumar1008/contracts-wizard) | Ink Smart Contract Wizard | [GitHub](https://github.com/amankumar1008/contracts-wizard) | ☐ | ☐ | ☐ | +| [TDSoftware](https://www.tdsoftware.de/) | Substrate IPFS Utilities | [GitHub](https://github.com/TDSoftware) | ☐ | ☐ | ☐ | +| [Ink Boxes Team](https://github.com/nerdsince98) | Ink Boxes | [GitHub](https://gitlab.com/nerdsince98/learning-ink/) | ☐ | ☐ | ☐ | +| [ParaSpell](https://github.com/paraspell) | ParaSpell Phase 2 | [GitHub](https://github.com/paraspell) | ☐ | ☐ | ☐ | From 08e60c4b451e7a5f936c037e4c07b00ac6b1a493 Mon Sep 17 00:00:00 2001 From: S E R A Y A Date: Fri, 11 Nov 2022 16:16:05 +0100 Subject: [PATCH 005/959] Update accepted_grant_applications.md Accept Subalfred M1 --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index a5747aa5b94..df4b35f6398 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -549,7 +549,7 @@ | [Polket](https://toearn.fun) | ToEarnFun | [GitHub](https://github.com/polketio/polket-node) | ☐ | ☐ | ☐ | | ALPHA LABS | Binary merkle tree | [GitHub](https://github.com/frisitano) | ☐ | ☐ | ☐ | | [Standard Protocol](https://standard.tech/) | New Order - a full onchain orderbook dex with indexers | [GitHub](https://github.com/standardweb3) | ☐ | ☐ | ☐ | -| [hack-ink](https://github.com/hack-ink) | Subalfred | [GitHub](https://github.com/hack-ink/subalfred) | ☐ | ☐ | ☐ | +| [hack-ink](https://github.com/hack-ink) | Subalfred | [GitHub](https://github.com/hack-ink/subalfred) | ☐ | ☒ | ☐ | ## 🏄‍♀️ Wave 16 - Fourth Quarter 2022 From a243381ecf49c64b89109236c7f5b441dd321a9c Mon Sep 17 00:00:00 2001 From: yyd106 Date: Mon, 14 Nov 2022 17:00:14 +0800 Subject: [PATCH 006/959] Update keysafe_network.md (#1274) --- applications/keysafe_network.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/applications/keysafe_network.md b/applications/keysafe_network.md index 67854b44e5f..fa6b305b2e0 100644 --- a/applications/keysafe_network.md +++ b/applications/keysafe_network.md @@ -131,13 +131,13 @@ The relevant [RFP is here](https://github.com/w3f/Grants-Program/blob/master/rfp ### Overview -- **Total Estimated Duration:** 3 months +- **Total Estimated Duration:** 8 months - **Full-Time Equivalent (FTE):** 3 - **Total Costs:** $27,000 (payable in Ethereum-USDT) ### Milestone 1 — Implement On-chain Modules -* **Estimated duration:** 2 month +* **Estimated duration:** 6 month * **FTE:** 3 * **Costs:** 15,000USD @@ -153,7 +153,7 @@ The relevant [RFP is here](https://github.com/w3f/Grants-Program/blob/master/rfp | 4. | Web Server | Provide meta-data management service for Keysafe users written in Rust, users can manage keys and authentication methods | | 5. | Polkadot.js | Add in encryption/decryption functionality to `@polkadot/keyring` and `@polkadot/extension` so that the protocol can run without the needs to read the private key of users. | -* **Estimated duration:** 1 month +* **Estimated duration:** 2 month * **FTE:** 3 * **Costs:** 12,000USD From f1d600bee5172d282c8566a661a12d94f1c4a9d6 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Mon, 14 Nov 2022 14:37:54 +0100 Subject: [PATCH 007/959] Update README.md Remove ink! and substrate, since we would support any polkadot native smart contract language or runtime development framework --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 8dba583e05b..71eeefde22e 100644 --- a/README.md +++ b/README.md @@ -29,7 +29,7 @@ ## :wave: Introduction -As part of our commitment to promoting the Web3 ecosystem, we offer a comprehensive grants program focused on funding software development and research efforts related to **Polkadot, Kusama, [Substrate](https://github.com/paritytech/substrate) and [ink!](https://github.com/paritytech/ink)**. For more information about the Web3 Foundation, please visit the [About page](https://web3.foundation/about/) on our website. +As part of our commitment to promoting the Web3 ecosystem, we offer a comprehensive grants program focused on funding software development and research efforts related to **Polkadot and Kusama**. For more information about the Web3 Foundation, please visit the [About page](https://web3.foundation/about/) on our website. ### Guidelines From 526328ef8e95ec19e10508408ec5005052b884c8 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Mon, 14 Nov 2022 16:14:59 +0100 Subject: [PATCH 008/959] Update README.md Add Nabil --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 71eeefde22e..bee7bdb7e39 100644 --- a/README.md +++ b/README.md @@ -101,6 +101,7 @@ In cases where a niche expert opinion is desirable, one of the committee members Evaluators are individuals able to evaluate the technology delivered as a result of the Grants Program. The committee has the right to add or remove evaluators on the basis of supermajority. +- [Nabil Abdellaoui](https://github.com/randombishop) - [David Hawig](https://github.com/Noc2) - [Diogo Mendonça](https://github.com/dsm-w3f) - [Sebastian Müller](https://github.com/semuelle) From dc2f9743c772644953c002764a3d744b241310d5 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Mon, 14 Nov 2022 16:17:59 +0100 Subject: [PATCH 009/959] Update README.md Adding Matteo Casonato --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index bee7bdb7e39..c26f5001e86 100644 --- a/README.md +++ b/README.md @@ -102,6 +102,7 @@ In cases where a niche expert opinion is desirable, one of the committee members Evaluators are individuals able to evaluate the technology delivered as a result of the Grants Program. The committee has the right to add or remove evaluators on the basis of supermajority. - [Nabil Abdellaoui](https://github.com/randombishop) +- [Matteo Casonato](https://github.com/0xCaso) - [David Hawig](https://github.com/Noc2) - [Diogo Mendonça](https://github.com/dsm-w3f) - [Sebastian Müller](https://github.com/semuelle) From e3a1e7b01ffd3469077209605a9262da4d314d48 Mon Sep 17 00:00:00 2001 From: Bu <116880440+budtr@users.noreply.github.com> Date: Mon, 14 Nov 2022 22:36:02 +0700 Subject: [PATCH 010/959] Add SubRelay application (#1252) * Add SubRelay application * Change SubRelay application --- applications/subrelay.md | 538 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 538 insertions(+) create mode 100644 applications/subrelay.md diff --git a/applications/subrelay.md b/applications/subrelay.md new file mode 100644 index 00000000000..d709988089a --- /dev/null +++ b/applications/subrelay.md @@ -0,0 +1,538 @@ +# SubRelay + +- **Team Name:** SubRelay +- **Payment Address:** 0x1aE740dC9F0F2f7404feA35bEb0D59105B9121Cf (USDT - Ethereum Network) +- **Level:** 2 + +## Project Overview :page_facing_up: + +### Overview +SubRelay is a no-code solution to build automation workflows on any Substrate-based chain. The application helps users to create their off-chain automated workflows by subscribing to on-chain events through the interface. We aimed to make the app easy for average users but remain a powerful tool for advanced users. With this in mind, we designed Subrelay to be generic and flexible with any use cases. Additionally, the SubRelay can integrate with any runtime of any blockchain building on the Substrate, such as Polkadot, Kusama, and Statemine. + +The app was motivated by our desire to monitor the on-chain events and send webhook requests to our internal system. We wanted to build a solution that not only can solve our problems but also benefit the entire ecosystem of Substrate/Polkadot. Our vision is to make SubRelay the most popular event relay service for any chain in the Polkadot ecosystem. + +### Project Details +#### Wireframe +##### Welcome screen & authentication + +image + + +image + +##### Workflow list + +image + +##### Create a new workflow +###### 1. Trigger + +image + +image + +image + +image + +image + +image + + +###### 2. Action + +image + +image + +image + +image + +##### Executions history + +image + + +#### Database schema + +``` + +Table user { + id varchar [pk] + address varchar +} + +Table chain { + uuid varchar [pk] + chain_id varchar // chain_id in block + created_at datetime + version varchar + name varchar + img_url varchar + config jsonb + latest boolean +} + +Table event { + id varchar [pk] + chain_uuid varchar + name varchar + description varchar + fields jsonb + sample jsonb +} + +Table workflow { + id varchar [pk] + user_id varchar + created_at datetime + updated_at datetime + status varchar +} + +Table workflow_log { + id varchar [pk] + started_at datetime + finished_at datetime + workflow_version_id varchar + input jsonb + status varchar +} + +Table workflow_version { + id varchar [pk] + workflow_id varchar + name varchar + chain_uuid varchar + created_at datetime + version varchar +} + +Table task_log { + task_id varchar pk + workflow_log_id varchar pk + started_at_at varchar + finished_at datetime + status boolean + output jsonb + input jsonb + } + +Table task { + id varchar [pk] + name varchar + workflow_version_id varchar + type varchar + config jsonb + depend_on varchar + } + +Ref: chain.uuid > event.chain_uuid +Ref: task.id > task_log.task_id +Ref: user.id > workflow.user_id +Ref: chain.uuid > workflow_version.chain_uuid +Ref: workflow_version.id > task.workflow_version_id +Ref: task.id > task.depend_on +Ref: workflow_version.workflow_id > workflow.id +Ref: workflow_log.workflow_version_id > workflow_version.id +Ref: workflow_log.id > task_log.workflow_log_id + +``` + + +#### API specs +##### ***GET** /chains* + +- Response +```json + [ + { + "uuid": "849e9dec-5ab8-11ed-9b6a-0242ac120002", + "name": "Polkadot", + "img_url": "string", + "version": "v1.2.0", + } + ] +``` + +##### ***GET** /chains/{chain_uuid}/events* + +- Response +```json + [ + { + "id": "849e9dec-5ab8-11ed-9b6a-0242ac120002", + "name": "balances.deposit", + "description": "string", + }, + { + "id": "849e9dec-5ab8-11ed-9b6a-0242ac120002", + "name": "balances.transfers", + "description": "string", + }, + { + "id": "849e9dec-5ab8-11ed-9b6a-0242ac120002", + "name": "ntf.minted", + "description": "string", + } + ] +``` + + +##### ***GET** /chains/{chain_uuid}/events/{event_id}* + +- Response +```json + { + "id": 123, + "name": "balances.deposit", + "description": "string", + "fields": [ + { + "name": "data.who", + "type": "string", + "description": "who sent" + }, + { + "name": "data.amount", + "type": "number", + "description": "" + }, + { + "name": "status", + "type": "string", + "description": "status of this event" + }, + { + "name": "extrinsic.name", + "type": "string", + "description": "this event belong to this extrinsic" + } + ], + "sample": { + "id": 123, + "name": "balances.deposit", + "description": "", + "data": { + "who": "", + "amount": 123 + }, + "status": "success", + "extrinsic": { + "name": "balances.deposit" + }, + "block": { + "hash": "", + "number": 123, + "timestamp": "" + } + } + } +``` + +##### ***GET** /workflows* + +- Query params + +| **Query Param** | **Description** | **Example** | +| ---| ---| --- | +| limit | The number of workflows per page | 10 | +| offset | page | 0 | +| search | Search workflow by name | "foo" | +| chain\_uuid | Filter workflows by chain UUID | 2 | +| status | Filter workflows by status. | "running" | + +- Response + +```json +{ + "workflows": [ + { + "id": 10, + "name": "name 1", + "chain": { + "uuid": "uasdasdsd", + "name": "Acala" + }, + "created_at": "2022-11-02T03:12:39.018Z", + "updated_at": "2022-11-02T03:12:39.018Z", + "status": "running" + } + ], + "limit": 10, + "offset": 0, + "total": 1 +} + +``` + +##### ***POST** /workflows* +- Request body +```json +{ + "name": "workflow 1", + "tasks": [ + { + "name": "trigger 1", + "type": "trigger", + "config": { + "event": "balances.deposit", + "chain_uuid": 1, + "conditions": [ + [ + { + "variable": "data.amount", + "operator": "greaterThan", + "value": 1 + } + ], + [ + { + "variable": "data.amount", + "operator": "lessThan", + "value": 10 + } + ] + ] + }, + "depend_on_name": null + }, + { + "name": "notify webhook", + "type": "notification", + "config": { + "channel": "webhook", + "config": { + "headers": { + "API_KEY": "encrypted" + } + "url": "https://webhook.com" + }, + "depend_on_name": "trigger 1" + } + } + ] +} +``` + +- Response +```json +{ + "id": 22, + "created_at": "2022-11-02T03:12:39.018Z", + "updated_at": "2022-11-02T03:12:39.018Z", + "status": "running", + "name": "workflow 1", + "chain": { + "uuid": "asdasdasd", + "name": "Acala" + }, + "tasks": [ + { + "id": 1, + "name": "trigger 1", + "type": "trigger", + "config": { + "event": "balances.deposit", + "chain_uuid": "asdasdasd", + "conditions": [ + [ + { + "variable": "data.amount", + "operator": "greaterThan", + "value": 1 + } + ], + [ + { + "variable": "data.amount", + "operator": "lessThan", + "value": 10 + } + ] + ] + }, + "depend_on": null + }, + { + "name": "notify webhook", + "type": "notification", + "config": { + "channel": "webhook", + "config": { + "headers": { + "API_KEY": "encrypted" + }, + "url": "https://webhook.com" + }, + "depend_on": 1 + } + } + ] +} +``` +##### ***DELETE** /workflows/{workflow_id}* +##### ***GET** /workflow/logs* +- Query params + +| **Query Param** | **Description** | **Example** | +| ---| ---| --- | +| limit | The number of logs per page | 10 | +| offset | page | 0 | +| search | Search logs by workflow name | "foo" | +| chain_uuid | Filter logs by workflow's chain uuid | 2 | +| status | Filter logs by status. | "running" | + +- Response + +```json +{ + "logs": [ + { + "id": 10, + "workflow": { + "id": 10, + "name": "name 1", + "chain": { + "id": 1, + "name": "Acala" + }, + }, + "started_at": "2022-11-02T03:12:39.018Z", + "finished_at": "2022-11-02T03:12:39.018Z", + "status": "success" + }, + { + "id": 11, + "workflow": { + "id": 10, + "name": "name 1", + "chain": { + "id": 1, + "name": "Acala" + }, + }, + "started_at": "2022-11-02T03:12:39.018Z", + "finished_at": "2022-11-02T03:12:39.018Z", + "status": "failed" + } + ], + "limit": 10, + "offset": 0, + "total": 2 +} +``` + + +#### Techstack +- Front-end: [Vue.js](https://vuejs.org/), [Quasar Framework](https://quasar.dev/) +- Back-end: + - API Framework: Node, [Nest](https://github.com/nestjs/nest) + - Database: [PostgreSQL](https://www.postgresql.org/) + - Queue: Redis + - Infrastructure: Docker + +### Ecosystem Fit + +As mentioned above, SubRelay can integrate with any Substrate-based chain, bringing a massive benefit to the Substrate/Polkadot ecosystem. + +There is a wide range of our target users, but we think there are a few main groups of the user: +- **Normal blockchain user:** The interface of SubRelay is designed to support normal users who want to do a simple task such as watching the change in their balance by setting a notification. + +- **Crypto experts:** Although SubRelay's interface is easy to use to support normal users who need a simple workflow, it also is a powerful tool for experts. There is no limitation on what can build with SubRelay. For example, a defi farmer can monitor their liquidity pools, borrowing, and lending positions, or an NFT trader can watch their favorite collections' prices. + +- **Developers/ Team:** From the developer's perspective, there is no easy way to integrate an existing system with a blockchain. Our solution will help the teams save time and resources to focus on solving their business requirements instead of wasting their time building a service to integrate with the chain. + +Web3Go MoonPush looks similar to our project, but SubRelay is more generic and flexible. There are a few key differences: +- SubRelay can integrate with any Substrate-based chain. +- SubRelay supports subscribing to any runtime events. +- SubRelay provides a highly customizable event filter and action configuration. +- SubRelay has log systems that allow users to manage workflow performance by recording all success and failure pipelines. + +## Team :busts_in_silhouette: + +### Team members +- Chi Tran - Team Leader +- Anh Thi Chieu +- Bu Le + +### Contact + +- **Contact Name:** Tran Thi Diem Chi +- **Contact Email:** ttdiemchi@gmail.com +- **Website:** http://subrelay.xyz + +### Legal Structure +We are very early and have not set up a legal identity. If necessary, we will set it up as soon as possible. Otherwise, we want to spend our resources on product development. + +### Team's experience +Our team has five-year experience in software development for SaaS startups, and provide custom enterprise solutions for top brands. We also have been spending more than a year in blockchain research and development so far. With these experiences, we know the best way to build a great product that connects web2 to web3. + +### Team Code Repos + +**Organization repos** +- https://github.com/subrelay +- https://github.com/subrelay/subrelay-api +- https://github.com/subrelay/interface + +**Team members** +- https://github.com/chidtr +- https://github.com/anhthichieu +- https://github.com/budtr + +## Development Roadmap :nut_and_bolt: +### Overview + +- **Total Estimated Duration:** 5 months +- **Full-Time Equivalent (FTE):** 1.5 +- **Total Costs:** 30,000 USD + +### Milestone 1: Core functions + +- **Estimated duration:** 2.5 months +- **FTE:** 1,5 +- **Costs:** 15000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide a basic tutorial that explains the concept of SubRelay, how to create a workflow, and other features | +| 0d. | Docker | We will provide a Dockerfile(s) for the self-hosted version | +| 1. | Feature: Authentication by PolkadotJs wallet | The dashboard and api will allow user to authentication by PolkadotJs wallet| +| 2. | Feature: Create a new workflow | Create a new workflow page which the same as the wireframe above. But Email, Telegram and Discord integrations will not in scope of this milestone.| +| 3. | Feature: List of workflows | A page display workflows of user same as the wireframe above.| +| 4. | Feature: Executions of workflows | A page display workflows execution history of user same as the wireframe above. | +| 5. | API | We will release an api version which include create workflow, list workflow and list workflow executions. | +| 6. | Integration | We will integrate the interface features (listed in 1, 2, 3, 4) with the api. | + + +### Milestone 2: Extensions development and testing + +- **Estimated duration:** 2,5 months +- **FTE:** 1,5 +- **Costs:** 15000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide the tutorial for the new features added in milestone 2 | +| 0c. | Testing and Testing Guide | The interface and API will be covered by unit tests and e2e tests. We will provide documentation on how to run the tests and setup CI to run the tests | +| 0d. | Docker | We will release a new Docker file which includes new features added in milestone 2 | +| 0e. | Article | We will publish an article that explains the concepts and features of SubRelay, and the grant | +| 1. | Feature: Email integration | Integrate with Email to send the notification about on-chain event.| +| 2. | Feature: Telegram integration | Integrate with Telegram to send the notification about on-chain event.| +| 3. | Feature: Discord integration | Integrate with Discord to send the notification about on-chain event. | +| 4. | Feature: Workflow execution detail | A page display workflow execution in detail.| +| 5. | API | We will release an api version which include email, telegram, discord integration and workflow exection detail | +| 6. | Integration | We will integrate the interface features (listed in 1, 2, 3, 4) with the api. | + +## Future Plans + +In the short-term plan, we will launch a community cloud version to get the tractions and feedback from the users to improve the product. +We will add more features such as parallel workflow, workflow templates, and user onboarding processes for the long-term plan. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website From 31bbb77e64ea6be59621dbedca146e097ab51c9f Mon Sep 17 00:00:00 2001 From: David Hawig Date: Mon, 14 Nov 2022 16:55:23 +0100 Subject: [PATCH 011/959] Update accepted_grant_applications.md Add SubRelay --- docs/accepted_grant_applications.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index df4b35f6398..746c28cfad3 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -569,4 +569,5 @@ | [TDSoftware](https://www.tdsoftware.de/) | Substrate IPFS Utilities | [GitHub](https://github.com/TDSoftware) | ☐ | ☐ | ☐ | | [Ink Boxes Team](https://github.com/nerdsince98) | Ink Boxes | [GitHub](https://gitlab.com/nerdsince98/learning-ink/) | ☐ | ☐ | ☐ | | [ParaSpell](https://github.com/paraspell) | ParaSpell Phase 2 | [GitHub](https://github.com/paraspell) | ☐ | ☐ | ☐ | +| [SubRelay](http://subrelay.xyz/) | SubRelay | [GitHub](https://github.com/subrelay) | ☐ | ☐ | ☐ | From e80ead2e3159fb4e0707fa2e274d884cd9648d71 Mon Sep 17 00:00:00 2001 From: Loaki07 <66478092+Loaki07@users.noreply.github.com> Date: Mon, 14 Nov 2022 21:34:30 +0530 Subject: [PATCH 012/959] Followup Grant Proposal - Dot Marketplace Phase 3: Milestone updates with decentralized court + decentralized storage + advanced search (#1205) * Create dot_marketplace-Phase3.md * Updated technical details for pallet/server/UI for each milestone * Update applications/dot_marketplace-Phase3.md Co-authored-by: S E R A Y A * Update applications/dot_marketplace-Phase3.md Co-authored-by: S E R A Y A * Update applications/dot_marketplace-Phase3.md Co-authored-by: S E R A Y A Co-authored-by: S E R A Y A --- applications/dot_marketplace-Phase3.md | 222 +++++++++++++++++++++++++ 1 file changed, 222 insertions(+) create mode 100644 applications/dot_marketplace-Phase3.md diff --git a/applications/dot_marketplace-Phase3.md b/applications/dot_marketplace-Phase3.md new file mode 100644 index 00000000000..3dd09dc87da --- /dev/null +++ b/applications/dot_marketplace-Phase3.md @@ -0,0 +1,222 @@ +# Dot Marketplace v2 + +- **Status:** Open +- **Project Name:** Dot Marketplace +- **Team Name:** Wow Labz +- **Payment Address:** 0xF13001401396AA866E8012f31fD939C7E83B8601 (USDT - ERC20) +- **Level:** 2 + +### Overview + +Links To Previous Approved Grants: +- [Phase 1](https://github.com/w3f/Grants-Program/blob/master/applications/dot_marketplace.md) +- [Phase 2](https://github.com/w3f/Grants-Program/blob/master/applications/dot_marketplace-phase2.md) + +This is phase 3 of Dot Marketplace, which is a general-purpose decentralized marketplace created as a Substrate pallet. + +- Dot Marketplace can be used by any decentralized project to float tasks and invite their community members to execute them for a reward. Its POC was developed during the Polkadot India Buildathon (2021). +- In the previous phases we have built a decentralised bounty platform and a decentralised court for dispute resolution. More details can be found on the respective grant proposals shared above. + + +### Project Details + +The current scope of work involves **milestone-based submissions** in which a project is divided into multiple configurable milestones(min 1 and max 5) to allow parallel or sequential execution. + +- Each project must have at least one milestone and can have a maximum of five milestones (configurable) +- Each milestone has its independent bidding system where multiple workers can place their bids +- The publisher can select a bid as per the requirement and ratings of the worker and other criteria that can be added to a user account. +- A worker can bid for multiple milestones of a single project based on their expertise. +- A project reaches completion only if all milestones in the project are completed and approved by the publisher. +- In our current implementation all milestones are independent, hence they can be completed and approved by the publisher irrespective of the overall project status. +- Based on the requirements, a publisher can add more milestones to a project even after it is pushed to the market, provided the total number of milestones does not exceed 5 (configurable) +- Decentralized IPFS Storage for project materials using NFTStorage Provider. Each material will have a unique CID that can be accessed by both Publisher and Worker. +- Advance Search by task tags, ids & title. +- The [decentralized court](https://github.com/WowLabz/dot-marketplace-v2) implemented in phase 2 is functional for each milestone of a project +- All of the above features will be updated as a new feature for the existing marketplace pallet. Similarly, the selekatal UI will be updated to showcase the same. +- A new file server written using the rocket framework will be provided for the integration with IPFS (using NftStorage). + +The flow of tasking pallet with milestone based submission + +![Tasking-Court-Flow4 drawio](https://user-images.githubusercontent.com/66478092/190300655-1d2085b3-b728-4ced-8238-f262a9c5c5f8.png) + + +### **Repository Hierarchy** + +```bash +node +├── build.rs +├── Cargo.toml +└── src + ├── chain_spec.rs + ├── cli.rs + ├── command.rs + ├── lib.rs + ├── main.rs + ├── rpc.rs + └── service.rs +pallets +├── pallet-chat +│ ├── Cargo.toml +│ ├── README.md +│ └── src +│ ├── benchmarking.rs +│ ├── lib.rs +│ ├── mock.rs +│ └── tests.rs +└── pallet-tasking + ├── Cargo.toml + ├── README.md + └── src + ├── benchmarking.rs + ├── lib.rs + ├── mock.rs + ├── utils.rs + └── tests.rs +runtime +├── build.rs +├── Cargo.toml +└── src + └── lib.rs +``` + +The current focus is to enhance the existing Substrate pallet and allied code base to get a basic yet functional marketplace up and running. + +### **Ecosystem Fit** + +We believe this work could be helpful for any Polkadot parachains/parathreads interested in including a marketplace with on-chain dispute resolution. + +- Almost all parachains/parathreads would find motivation in encouraging their community members to contribute meaningfully to their roadmap. This can be achieved by utilizing a marketplace like Dot Marketplace, where technical, marketing, or governance-centric projects can be published as bounties. And community members are invited to bid for and execute them. +- A milestone-based submission will enhance the functionality of the marketplace and provide a more comprehensive user experience for both the worker and the publisher. +- The on-chain court will act as a dispute resolution mechanism between users involved in a project. A set of community members meeting specific criteria get to be a part of the jury for the dispute and cast votes, based on which a decision is reached. +- To facilitate easier communication between a customer and a worker, a one-to-one chat feature is also created. + +## **Team 👥** + +### **Team members** + +- [**Amit Singh**](https://www.linkedin.com/in/startupamit/) [ Product Manager ] +- [**Roshit Omanakuttan**](https://www.linkedin.com/in/roshit/) [ Technical Architect ] +- [**Loakesh Indiran**](https://www.linkedin.com/in/loakesh-indiran-8a2282140) [ Full Stack Developer ] +- [**Tejas Gaware**](http://www.linkedin.com/in/tejas-vijay-1430a3190) [ Backend Developer ] +- [**Rajat Petwal**](https://www.linkedin.com/in/rajat-petwal-947440197/) [ Backend Developer ] + +### **Contact** + +- **Contact Name:** Amit Singh +- **Contact Email:** amit (dot) singh (@) wowlabz.com +- **Website:** [http://www.wowlabz.com](https://www.wowlabz.com/) +- **Project Website:** [Dot marketplace website](https://dotmarketplace.co/) + +### **Legal Structure** + +- **Registered Address:** Wow Labz, 2Gethr Cowork, Tower B, Mantri Commercio, Outer Ring Rd, Bellandur, Bengaluru, Karnataka, India 560103 +- **Registered Legal Entity:** Wow Internet Labz Private Limited + +### **Team's experience** + +Dot Marketplace is being built by the team at Wow Labz. Wow Labz is one of India's leading turnkey product development companies. The team is also building Socialli - an interoperable metaverse protocol on Polkadot. Additionally the team at Wow Labz has built [Polkadot India](https://www.polkadotindia.org/) - a 15,000+ community of polkadot enthusiasts predominantly from the Indian region. The team has previously built a decentralized storage protocol called Lake Network - [https://lakenetwork.io/](https://lakenetwork.io/) in addition to multiple dApps on Ethereum, Stellar, EOS, and Hyperledger. + +A list of centralized and decentralised apps published can be found [here](https://www.wowlabz.com/work/). + +### **Team Code Repos** + +- [https://github.com/orgs/WowLabz/projects](https://github.com/orgs/WowLabz/projects) +- [https://github.com/WowLabz/tasking_backend](https://github.com/WowLabz/tasking_backend) +- [https://github.com/WowLabz/tasking_frontend](https://github.com/WowLabz/tasking_frontend) +- [https://github.com/WowLabz/yoda_creator_economy_node](https://github.com/WowLabz/yoda_creator_economy_node) +- [https://github.com/WowLabz/dot-marketplace-v2](https://github.com/WowLabz/dot-marketplace-v2) + +## **Development Status 📖** + +- Here's a link to the approved grant proposal for the [first phase](https://github.com/w3f/Grants-Program/blob/master/applications/dot_marketplace.md) and [second phase](https://github.com/w3f/Grants-Program/blob/master/applications/dot_marketplace-phase2.md) +- We are in touch with @takahser and @Rouven from the Web 3 Grants and Treasuries team, respectively. + +## **Development Roadmap** 🔩 + +****Overview**** + +* **Total Estimated Duration:** 2.0 Months +* **Full-Time Equivalent (FTE):** 2.39 +* **Total Costs:** 29,925 USD + + +### **Milestone 1** + +* **Estimated duration:** 3.0 weeks +* **FTE: 1** +* **PTE: 2** +* **Costs:** 12,725 USD + +The main deliverable for this milestone is to facilitate the creation of a project that can accommodate multiple milestones that may or may not depend on each other. These functionalities will be implemented as an upgrade to the existing marketplace pallet. + +| Sr no. | Deliverable | Description | +| --- | --- | --- | +| 0a | License | Apache 2.0 | +| 0b | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet. | +| 0c | Testing Guide | Functions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build. | +| 0d | Docker Image | Docker image of the build | +| 1 | Project Structure | The existing application only allows one milestone per project. Phase 3 modifies it to allow a publisher to add multiple milestones under the same project. | +| 2 | Multiple Bidders| Multiple bidders can now bid for the same milestone, and the publisher can choose one worker based on the bidder ratings | +| 3 | Escrow | Multiple subaccounts are created for a project to account for each milestone and make it easier to store all funds for transfer/exchange. | + +### **Milestone 2** + +* **Estimated duration:** 2.0 weeks +* **FTE:** 1 +* **PTE:** 2 +* **Costs:** 9,225 USD + + +In continuation to previous work, this milestone involves the creation of an on-chain decentralized court to handle dispute resolution. Each milestone can go into a dispute on the same scope as mentioned in the second phase of dot marketplace. The other milestones in a project are not affected by the dispute of one of the milestones. The court pallet will be upgraded to support these new features. + +| Sr no. | Deliverable | Description | +| --- | --- | --- | +| 0a | License | Apache 2.0 | +| 0b | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet. | +| 0c | Testing Guide | Functions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build. | +| 0d | Docker Image | Docker image of the build | +| 1 | Decentralized Court Module | An on-chain decentralized court for dispute resolution within the ecosystem. | +| 1a | Disapprove Milestone | In the case of a customer not being satisfied with the work submitted by the service provider (worker). A set of jurors is shortlisted (court summon) to resolve the dispute and pass a verdict. | +| 1b | Disapprove Rating | The customer or the service provider, once they have received their rating for a particular milestone and are not satisfied with it. | +| 1c | General Dispute | A general dispute function for cases that do not fall under the categories mentioned in 1a and 1b. | +| 2 | Voting module | Each juror can review the dispute and cast their vote, which also includes their rating for both the customer and the worker. After two days, all the juror votes are counted, and a winner is identified. | +| 3 | Frontend App | Supporting frontend UI to test the aforementioned functionality. | + +### **Milestone 3** + +* **Estimated duration:** 3.0 weeks +* **FTE:** 1 +* **PTE:** 2 +* **Costs:** 7975 USD + + +The main deliverables in this milestone are to use decentralized IPFS based storages to store all the files realated to tasks & advanced search. A file server integrated to nft storage will provided, using rocket framework & the search feature will be an update to the makerplace pallet. The skeletal UI will also be updated to showcase all the new features in Phase3. + +| Sr no. | Deliverable | Description | +| --- | --- | --- | +| 0a | License | Apache 2.0 | +| 0b | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use DOT Marketplace and understand the flow of tasking pallet. | +| 0c | Testing Guide | Functions will be covered by unit tests, the documentation will describe how to run these tests. We will also provide scripts to help deploy, run and test the build. | +| 0d | Docker Image | Docker image of the build | +| 1 | Decentralized Storage | All tasks related docs will be stored on a decentralized IPFS platform. | +| 2 | Advanced Search | Search based on task progress, tags, tasks or milestone id's. | +| 3 | Frontend App | Supporting frontend UI to test the aforementioned functionality. | +| 4 | Website | Dedicated one-page website for Dot Marketplace. | +| 5 | Article | Website article showing motivation behind phase 3 of dot marketplace and how to make the best use of it. | + +### **Additional Project Details** + +* Technology stack being used + * Rust, Substrate, React, Python, centralized cloud storage + +### **Future Plans** + +This is the last phase in our current roadmap. Post this we would focus on partnerships with chains on the dotsama ecosystem for integrating DotMarketplace as their native bounty management tool (this work has already started). If future, if the traction is great, we could create a fresh proposal for an excellent UI or integrate DotMarketplace within PolkaJS Apps itself with native support for multiple tokens besides DOT. + +### + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website, Polkadot India Buildathon + +* We have been working on this roadmap since we applied for the Web3 grant From 1941babb4f82ae44f3f9fb199886f8267b35ad82 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Mon, 14 Nov 2022 17:33:04 +0100 Subject: [PATCH 013/959] Update accepted_grant_applications.md wowlabz --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 746c28cfad3..060d2ae9519 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -570,4 +570,4 @@ | [Ink Boxes Team](https://github.com/nerdsince98) | Ink Boxes | [GitHub](https://gitlab.com/nerdsince98/learning-ink/) | ☐ | ☐ | ☐ | | [ParaSpell](https://github.com/paraspell) | ParaSpell Phase 2 | [GitHub](https://github.com/paraspell) | ☐ | ☐ | ☐ | | [SubRelay](http://subrelay.xyz/) | SubRelay | [GitHub](https://github.com/subrelay) | ☐ | ☐ | ☐ | - +| [Wow Labz](http://www.wowlabz.com) | Dot Marketplace Phase 3 | [GitHub](https://github.com/orgs/WowLabz) | ☐ | ☐ | ☐ | From 30036c342acd4966c4fd8356363184382d52cb8c Mon Sep 17 00:00:00 2001 From: David Hawig Date: Mon, 14 Nov 2022 20:22:55 +0100 Subject: [PATCH 014/959] Update accepted_grant_applications.md Fix links --- docs/accepted_grant_applications.md | 32 ++++++++++++++--------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 060d2ae9519..a90a97db058 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -11,25 +11,25 @@ ## Table of Contents - [2019](#2019) - - [🏄‍♀️ Wave 1 - First Quarter 2019](#surfing_woman-wave-1---first-quarter-2019) - - [🏄‍♀️ Wave 2 - Second Quarter 2019](#surfing_woman-wave-2---second-quarter-2019) - - [🏄‍♀️ Wave 3 - Third Quarter 2019](#surfing_woman-wave-3---third-quarter-2019) - - [🏄‍♀️ Wave 4 - Fourth Quarter 2019](#surfing_woman-wave-4---fourth-quarter-2019) + - [🏄‍♀️ Wave 1 - First Quarter 2019](#%EF%B8%8F-wave-1---first-quarter-2019) + - [🏄‍♀️ Wave 2 - Second Quarter 2019](#%EF%B8%8F-wave-2---second-quarter-2019) + - [🏄‍♀️ Wave 3 - Third Quarter 2019](#%EF%B8%8F-wave-3---third-quarter-2019) + - [🏄‍♀️ Wave 4 - Fourth Quarter 2019](#%EF%B8%8F-wave-4---fourth-quarter-2019) - [2020](#2020) - - [🏄‍♀️ Wave 5 - First Quarter 2020](#surfing_woman-wave-5---first-quarter-2020) - - [🏄‍♀️ Wave 6 - Second Quarter 2020](#surfing_woman-wave-6---second-quarter-2020) - - [🏄‍♀️ Wave 7 - Third Quarter 2020](#surfing_woman-wave-7---third-quarter-2020) - - [🏄‍♀️ Wave 8 - Fourth Quarter 2020](#surfing_woman-wave-8---fourth-quarter-2020) + - [🏄‍♀️ Wave 5 - First Quarter 2020](#%EF%B8%8F-wave-5---first-quarter-2020) + - [🏄‍♀️ Wave 6 - Second Quarter 2020](#%EF%B8%8F-wave-6---second-quarter-2020) + - [🏄‍♀️ Wave 7 - Third Quarter 2020](#%EF%B8%8F-wave-7---third-quarter-2020) + - [🏄‍♀️ Wave 8 - Fourth Quarter 2020](#%EF%B8%8F-wave-8---fourth-quarter-2020) - [2021](#2021) - - [🏄‍♀️ Wave 9 - First Quarter 2021](#surfing_woman-wave-9---first-quarter-2021) - - [🏄‍♀️ Wave 10 - Second Quarter 2021](#surfing_woman-wave-10---second-quarter-2021) - - [🏄‍♀️ Wave 11 - Third Quarter 2021](#surfing_woman-wave-11---third-quarter-2021) - - [🏄‍♀️ Wave 12 - Fourth Quarter 2021](#surfing_woman-wave-12---fourth-quarter-2021) + - [🏄‍♀️ Wave 9 - First Quarter 2021](#%EF%B8%8F-wave-9---first-quarter-2021) + - [🏄‍♀️ Wave 10 - Second Quarter 2021](#%EF%B8%8F-wave-10---second-quarter-2021) + - [🏄‍♀️ Wave 11 - Third Quarter 2021](#%EF%B8%8F-wave-11---third-quarter-2021) + - [🏄‍♀️ Wave 12 - Fourth Quarter 2021](#%EF%B8%8F-wave-12---fourth-quarter-2021) - [2022](#2022) - - [🏄‍♀️ Wave 13 - First Quarter 2022](#surfing_woman-wave-13---first-quarter-2022) - - [🏄‍♀️ Wave 14 - Second Quarter 2022](#surfing_woman-wave-14---second-quarter-2022) - - [🏄‍♀️ Wave 15 - Third Quarter 2022](#surfing_woman-wave-15---third-quarter-2022) - - [🏄‍♀️ Wave 16 - Fourth Quarter 2022](#surfing_woman-wave-16---fourth-quarter-2022) + - [🏄‍♀️ Wave 13 - First Quarter 2022](#%EF%B8%8F-wave-13---first-quarter-2022) + - [🏄‍♀️ Wave 14 - Second Quarter 2022](#%EF%B8%8F-wave-14---second-quarter-2022) + - [🏄‍♀️ Wave 15 - Third Quarter 2022](#%EF%B8%8F-wave-15---third-quarter-2022) + - [🏄‍♀️ Wave 16 - Fourth Quarter 2022](#%EF%B8%8F-wave-16---fourth-quarter-2022) # 2019 From c32346501a553d39fa990fc268111cd1d340d949 Mon Sep 17 00:00:00 2001 From: Nabil Abdellaoui Date: Tue, 15 Nov 2022 09:39:09 -0500 Subject: [PATCH 015/959] Update accepted_grant_application (#1275) DotPulse milestone 1 delivery accepted --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index a90a97db058..338469ed1fe 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -555,7 +555,7 @@ | Team | Project | Link | Terminated | First Delivery | Completed | :--- | :------ | :--- | :--------: | :------------: | :-------: | -| [CrossChain Labs](https://github.com/CrossChainLabs) | DotPulse | [GitHub](https://github.com/CrossChainLabs) | ☐ | ☐ | ☐ | +| [CrossChain Labs](https://github.com/CrossChainLabs) | DotPulse | [GitHub](https://github.com/CrossChainLabs) | ☐ | ☒ | ☐ | | [Jett Hays](https://github.com/jettblu) | Distributed Key Management | [GitHub](https://github.com/KryptikApp) | ☐ | ☐ | ☐ | | [NexToken Technology](https://github.com/NexTokenTech) | TREX - Timed Release Encryption Xing chains | [GitHub](https://github.com/NexTokenTech/TREX) | ☐ | ☐ | ☐ | | [Blockcoders](http://blockcoders.io/) | Cross-Consensus Messaging Software Development Kit | [GitHub](https://github.com/blockcoders) | ☐ | ☐ | ☐ | From 72152200fdfc5d6d799bdc044c2e27f2cc9d174a Mon Sep 17 00:00:00 2001 From: Grzegorz Sieczkowski <59612552+gsieczkowski10clouds@users.noreply.github.com> Date: Tue, 15 Nov 2022 07:00:13 -0800 Subject: [PATCH 016/959] Grant application - Crowdloan Front End Template (#1211) --- applications/crowdloan_frontend_template.md | 189 ++++++++++++++++++++ 1 file changed, 189 insertions(+) create mode 100644 applications/crowdloan_frontend_template.md diff --git a/applications/crowdloan_frontend_template.md b/applications/crowdloan_frontend_template.md new file mode 100644 index 00000000000..e6081f8aa58 --- /dev/null +++ b/applications/crowdloan_frontend_template.md @@ -0,0 +1,189 @@ +# Crowdloan Front End Template + +- **Team Name:** 10Clouds Sp. z o.o. +- **Payment Address:** 0xa79aa9572c7e1f8909fcc9674d676b73d5a71faa (aUSD) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +Responding to RFP: https://github.com/w3f/Grants-Program/blob/master/rfps/open/crowdloan_front_end_template.md + +### Overview + +A front-end white-label template for teams to use to easily build their Polkadot Crowdloan websites. + +### Project Details + +The overall objective of this project is to provide a white-label solution to teams to be able to plug into and offer all the information users need to contribute to their Crowdloan. In essence, it's a collection of: + +1. Project information +2. Rewards Schema +3. Current contributions +4. Time left in Crowdloan and competition +5. Contribute CTA +6. After the Crowdloan + +All of the above should be done style agnostic so that the project can plug their own look and feel into the site. +(as per RFP) + +### Ecosystem Fit + +Defined by RFP + +## Team :busts_in_silhouette: + +### Team members + +- Product Delivery Manager - Jedrzej Wencka +- Tech Lead - Aleksander Krasnicki +- React - Maciej Topor +- Design Lead - Krzysztof Juszczyk +- UX & Product Designer - Paweł Poterała + + +### Contact + +- **Contact Name:** Edgar Czop +- **Contact Email:** edgar.czop@10clouds.com +- **Website:** https://10clouds.com/ + +### Legal Structure + +- **Registered Address:** ul. Chmielna 73, 00-801 Warsaw, Poland +- **Registered Legal Entity:** 10Clouds Sp. z o.o. (Ltd.) + +### Team's experience + +The team was involved in creating an internal NFT Marketplace white-label (https://marketplace.10clouds.io). As the name suggests it's a website that allows mint and trade NFTs between users. It is strongly inspired by OpenSea and follows the same lazy minting pattern. After login with Metamask user can customize the profile, create collections, and start lazy-minting NFTs. The website contains extensive search/filters for collections and NFTs. An NFT can be created as _Open for offers_ which means another user can offer a price for which they want to buy it and the owner can accept any of them. The other way of selling is the „Buy now" option which allows you to sell NFTs for a set, fixed price. In both scenarios, the NFT is minted during the sale process and transferred to the new owner. + +The app is written in Next.js on the front-end and contains our own Smart Contracts currently deployed on Goerli testnet, and the Backend is written in Python with GraphQL. We have our own subgraph created in The Graph to aggregate the information about events emitted from our contracts (to update the UI accordingly). + +### Team Code Repos + +- https://github.com/10clouds + +- Maciej Topor https://github.com/maciejt10c +- Aleksander Krasnicki https://github.com/plakak + +### Team LinkedIn Profiles (if available) + +- [Product Delivery Manager - Jedrzej Wencka](https://www.linkedin.com/in/jedrzej-wencka-94382137/) +- Tech Lead - Aleksander Krasnicki +- [React - Maciej Topor](https://www.linkedin.com/in/maciej-topor/) +- [Design Lead - Krzysztof Juszczyk](https://www.linkedin.com/in/juszczyk/) +- UX & Product Designer - Paweł Poterała + + +## Development Status :open_book: + +We are currently in a very initial phase of gathering benchmarks for the approach and setting the general approach to deliver an experience that fits the target audience. + +From our initial research we came to the conclusion that the solution should follow these traits: + +### Using a Jamstack approach & Webflow template + +We aim to provide front-end templates that can be used with one major static site generator (SSG). This follows similar approaches like Github Pages templates for projects that contain the most important information and link-stubs to make it easy for Github projects to present themselves. + +The Jamstack will allow us to leverage the vast community behind it for future involvement of customisations and ports to other SSGs as is evidenced by the activities of these communities who are eager to port interesting templates to their SSG of choice. + +In addition to this we plan to create a Webflow template variant for teams who are more comfortable with it. Optionally we can also publish the Figma design as a basis for custom layouts by the community. + +### One Page approach + +We will also suggest a One Page or Single Page approach that, while still having the option for a menu, presents all information in one page as the name suggests. This has the following advantages: + +- **Most simple approach for projects.** Projects often underestimate the effort to create content and at the same time keep certain information to a digestible length +- **Less scope allows more variants.** If we limit the scope to a single page, we can more easily provide additional template designs that follow the structure but still give some individuality for each project. + +### SSG support (Jamstack only) + +We aim to start with the support of Gatsby, a popular React-based choice for SSGs, with a vast community of its own. An initial survey of the Parity community should be done to see whether these assumptions match and should be revised. + +When it comes to other SSGs, the ports can either be motivated by further grants or left to the community of open source volunteers. As mentioned before, there is an intrinsic motivation of each SSG’s community to port popular templates. + +**Deployment choices (Jamstack only)** + +The Jamstack approach allows the community to use virtually every popular way of hosting the project sites. We are assessing whether it is beneficial to include a “Deploy to Netlify” button in the projects as well to lower the initial barrier. However, projects will be able to deploy their pages to (but not be limited): + +- Netlify +- Github Pages +- Gitlab Pages +- Vercel +- Cloudflare +- AWS S3 (and similar solutions) + +### Easy to get started +We’re assuming that the approach is also a familiar way for the Parity community to get started with their project pages. It’s as simple as fork, customize, deploy. + +For parts of the community who are less comfortable with the Jamstack approach we will provide a Webflow template as well. + +### Illustrative Examples + +- https://github.blog/2012-04-02-instantly-beautiful-project-pages/ +- https://pages.github.com/ +- https://government.github.com/ +- https://github.com/collections/github-pages-examples +- … + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4-5 weeks +- **Full-Time Equivalent (FTE):** 2 (Product Designer & React Developer) + Support Team (PDM, Leads, UX Designer) +- **Total Costs:** 30,000 USD + +### Milestone 1 + +- **Estimated duration:** 4-5 weeks +- **FTE:** 2 (as above) +- **Costs:** 30,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0a. | License | MIT or TBD | +| 0b. | Documentation | For both approaches (Webflow & Jamstack) we provide how-to guides. Jamstack will be documented in the Github repo. | +| 0c. | Article | We will publish an article presenting the templates and how to use them. | +| 1a. | Benchmarking | Design research of existing Crowdloan pages and other one pages designs, like Github project pages templates.
This will allow us to synthesize viable options of the page designs | +| 1b. | Design Direction Prototype | Aiming to create as many medium to high-fidelity dd prototypes as possible that allows the Grants team and the community to have an input on the design direction
The aim is to have the prototypes at 25%-50% completeness, to see major components/features and the general design direction. This way we don't waste time on dismissed design directions.
The designs should follow good practices in general without requiring additional research | +| 1c. | Repo Setup | Repo setup incl. base libraries/frameworks, initial technical documentation. Undesigned base scaffold. Allows the implementation to be simplified by forking | +| 2. | Jamstack implementation in Gatsby | One (1) chosen design direction

Minimum sections:
- Project information
- Rewards Schema
- Current contributions
- Time left in Crowdloan and competition
- Contribute CTA
- After the Crowdloan

Implemented as One Page Design | +| 3. | Webflow implementation | One (1) chosen design direction

Minimum sections:
- Project information
- Rewards Schema
- Current contributions
- Time left in Crowdloan and competition
- Contribute CTA
- After the Crowdloan

Implemented as One Page Design | +| 4. | Figma Template Publishing | Allows to use it for other solutions | + + + + + +## Future Plans + +When provided with the initial set of templates and their usage instructions, we envision the following: +- Creating a hub repo that also uses a Jamstack approach to give a list of available templates, allowing the community to preview the templates easily and contribute templates or forks to other SSGs in a convenient place + The hub could also include: +- Good content practices partially provided by our team of UX writers + - FAQs + - Tips and Tricks taken from successful Crowdloans + + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Multiple contact people from Parity (e.g. Alberto Navarro or Richard Casey). + +**Work we have already done** + +- [Crescent](https://www.crescent.app/) + ![image](https://i.imgur.com/gLw8g3V.png) +- [Solo music](https://www.solomusic.io/) + ![image](https://i.imgur.com/ZWtJPve.png) +- [LevelField](https://www.levelfield.us/) + ![image](https://i.imgur.com/Zr9d4fu.png) +- [G-coin by Emergent Technology](https://gcoin.com/) + ![image](https://i.imgur.com/1OD1Jtg.png) +- [Omise](https://www.omise.co/) + ![image](https://i.imgur.com/ElSnQtX.png) + +We contributed to Devnet support SLA for parachains. \ No newline at end of file From f5c99d167219dc493ef577dcf396b904312e85be Mon Sep 17 00:00:00 2001 From: David Hawig Date: Tue, 15 Nov 2022 16:07:37 +0100 Subject: [PATCH 017/959] Update accepted_grant_applications.md Add Crowdloan Front End Template --- docs/accepted_grant_applications.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 338469ed1fe..71c79e0684d 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -571,3 +571,4 @@ | [ParaSpell](https://github.com/paraspell) | ParaSpell Phase 2 | [GitHub](https://github.com/paraspell) | ☐ | ☐ | ☐ | | [SubRelay](http://subrelay.xyz/) | SubRelay | [GitHub](https://github.com/subrelay) | ☐ | ☐ | ☐ | | [Wow Labz](http://www.wowlabz.com) | Dot Marketplace Phase 3 | [GitHub](https://github.com/orgs/WowLabz) | ☐ | ☐ | ☐ | +| [10Clouds Sp. z o.o.](https://10clouds.com/) | Crowdloan Front End Template | [GitHub](https://github.com/10clouds) | ☐ | ☐ | ☐ | From 9b8b6db7c52695ef322e08fcaf0b87e39cba4bb6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Sebastian=20M=C3=BCller?= Date: Tue, 15 Nov 2022 17:42:46 +0100 Subject: [PATCH 018/959] Update accepted_grant_applications.md --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 71c79e0684d..5f89e1db274 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -535,7 +535,7 @@ | [Uke](https://github.com/Uke-Messaging) | Uke Messaging - PoC - Phase 1 | [GitHub](https://github.com/Uke-Messaging) | ☒ | ☐ | ☐ | | [Redstone Network](https://github.com/difttt) | Redstone Network | [GitHub](https://github.com/difttt) | ☐ | ☐ | ☐ | | [JURIMETRIC TECNOLOGIA LTDA](https://www.jurimetric.com.br/) | Polkadart | [GitHub](https://github.com/rankanizer/polkadart) | ☐ | ☐ | ☐ | -| [Skye Kiwi](https://skye.kiwi/) | Choko Wallet | [GitHub](https://github.com/skyekiwi) | ☐ | ☐ | ☐ | +| [Skye Kiwi](https://skye.kiwi/) | Choko Wallet | [GitHub](https://github.com/skyekiwi) | ☐ | ☒ | ☐ | | [Popular Coding](https://www.popularcoding.com/) | Ventur | [GitHub](https://github.com/popular_coding) | ☐ | ☒ | ☐ | | [Asylum](https://asylum.space/) | Asylum follow-up 1 | [GitHub](https://gitlab.com/asylum-space/) | ☐ | ☒ | ☐ | | [Cyril Carlier](https://github.com/CrommVardek) | Maki| [GitHub](https://github.com/CrommVardek) | ☐ | ☐ | ☐ | From 3c3196dadb9e406000f4a41d9df9f0e00792a9bc Mon Sep 17 00:00:00 2001 From: Diogo <112647953+dsm-w3f@users.noreply.github.com> Date: Wed, 16 Nov 2022 09:23:18 -0300 Subject: [PATCH 019/959] Update accepted_grant_applications.md (#1277) --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 5f89e1db274..06922e9f775 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -525,7 +525,7 @@ | [Veridise](https://veridise.com/) | Vanguard | [GitHub](https://github.com/Veridise/Vanguard) | ☐ | ☐ | ☐ | | [Karolis Ramanauskas](https://krl.is/) | Generic Sybil-Resistant Faucet | [GitHub](https://github.com/karooolis) | ☐ | ☒ | ☒ | | [LimeChain](https://limechain.tech/) | Research feasibility for a Go Runtime | [GitHub](https://github.com/LimeChain) | ☐ | ☒ | ☒ | -| [Jim Yam](https://github.com/JimYam) | daos | [GitHub](https://github.com/daos-org/daos.git) | ☐ | ☐ | ☐ | +| [Jim Yam](https://github.com/JimYam) | daos | [GitHub](https://github.com/daos-org/daos.git) | ☐ | ☒ | ☐ | | [Green Lemon](https://github.com/GreenLemonProtocol) | Green Lemon Protocol | [GitHub](https://github.com/GreenLemonProtocol) | ☐ | ☒ | ☐ | | [Stardust Labs Inc.](https://stardust.finance/) | Integrating ISO-8583 | [GitHub](https://github.com/adit313/) | ☐ | ☒ | ☒ | | [TwinP](https://www.linkedin.com/in/elioprifti/) | Escrow Pallet | [GitHub](https://github.com/herou) | ☐ | ☒ | ☒ | From 9eb01ab2d211d0e26c0b177a018927985ddf737c Mon Sep 17 00:00:00 2001 From: David Date: Wed, 16 Nov 2022 14:50:52 +0100 Subject: [PATCH 020/959] Faterium application (#1264) * Add Faterium application * Alter Faterium grant proposal, add more details, schemes, and wireframes * Add Ethereum USDT payment address --- applications/faterium.md | 258 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 258 insertions(+) create mode 100644 applications/faterium.md diff --git a/applications/faterium.md b/applications/faterium.md new file mode 100644 index 00000000000..319e80fc22f --- /dev/null +++ b/applications/faterium.md @@ -0,0 +1,258 @@ +# W3F Grant Proposal + +- **Project Code Name:** Faterium +- **Team Name:** DodoRare, Inc. +- **Payment Address:** 0x6f083B9888D65A7CA7b8936982BE8Be328eF6d56 (ERC20 USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +Faterium is a decentralized voting platform that provides business tools for content creators to monetize their projects and directly engage the community on important decisions. It helps game developers, creators and artists to easily create own assets, distribute them and earn by providing crowdfunding polls on various topics that are important to their community. + +### Problem Summary + +Services like [Patreon](https://patreon.com/) help content creators get support from their community, and [Kickstarter](https://www.kickstarter.com/) helps raise money for a new creative projects. These are very good services and everyone is used to them, but we see opportunity here: the community can’t directly influence the creation process and be truly involved into it. + +### Solution Summary + +We have found a solution that can give creators new opportunities to monetize their project and directly involve their community in the creation process through regular voting and events with valuable rewards. + +We will provide a simple interface where creators can create special polls in a few clicks, set which currency will be used for voting, and then invite the community to participate in it. + +Also, we will make convenient tools for creating, distributing and integrating of own assets and NFTs, thanks to which people who are not familiar with Web3 will be able to use the power of decentralization in their projects such as games, online books, movies and comics. + +We integrate social elements into the platform, such as rating, discussion forums or community-created proposals. And it will give creators even more ways to interact with the community. + +In addition, we will make SDKs and APIs to help integrate our platform into existing services and projects, such as games, websites for reading books or comics, or websites for watching movies, which will open up endless possibilities for adopting the technology. + +### Glossary + +- **User Profile** - a collection of settings and information associated with a user. +- **Community** - a customizable space where polls, discussions, and events of a specific community will be located, it can be either a personal space or a project space. +- **Crowdfunding Polls** - a way for creators to decide what community wants and raise money for a project or idea. Authors themselves determine which currency they want to use for voting and what percentage they will receive after the end of the poll. +- **Poll Rewards** - any kind of reward that users can receive after winning the poll. It can be either a unique NFTs or any gifts personally from the author of the poll. + +### Infrastructure Scheme + +![Faterium - Faterium Platform](https://i.imgur.com/8FRSNOz.jpeg) + +### Wireframes + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ 1. Main Page + + 2. Categories + + 3. Community +
+ + + + + +
+ 4. Poll + + 5. User Profile + + 6. Create Community +
+ + + + + +
+ 7. Create Asset + + 8. Create Poll + + 9. Profile Settings +
+ + + + + +
+ +### Substrate and Backend API + +![image](https://user-images.githubusercontent.com/24860875/201778800-35f70227-5f26-49db-9123-e99e47711c39.png) + +### Usecases + +The Faterium platform can be useful for a large pool of content creators and projects. Such as game developers, comic and manga artists, book writers, movie and anime creators, bloggers and streamers, journalists and politicians, etc. Faterium can be used in all areas where the creators would like to give the community the tools to vote and influence. Now, we would like to show a couple of interesting use cases of the platform. + +#### Simplified user flow diagram + +![image](https://user-images.githubusercontent.com/24860875/201778526-3cf974df-a33b-4979-8275-67f4fc04480a.png) + +#### Comics Creator + +Imagine talented comics creator - Bob Johnson, that has several popular multi-series comics and thousands of fans waiting for new chapters. Bob is looking for a new way to get funding for his projects, and at the same time get feedback from his community. + +He comes to the Faterium platform, configures user profile and creates his first crowdfunding poll, in less than 30 minutes. Bob sets the duration of the poll to 3 days, selects DOT as the voting currency and also sets what will happen after the poll ends - 50% of winners assets go to the poll creator, and winners will receive remaining 50% of assets alongside unique NFTs as reward. + +In the poll, he asks his community a question: "Which comic should I develop this month?". Also, Bob describes options in the poll and give detailed information about what he will do after the end of the poll. Then he posts the poll with unique link in his social media. Fans are happy that the author is preparing new series of comics and they decide to help him by voting. They log in via the [polkadot{.js} extension](https://polkadot.js.org/extension/), choose one of the options in the poll and send assets. + +After the end of the poll, the Bob receives finances that will help him to create new series. At the same time, fans took part in an important decision and supported their favorite author, and of course were rewarded with rare NFTs! Looks nice! + +#### Game Developer + +Let's look at another example - a famous game developer. The developer wants to launch the game on as many platforms as possible, so he needs to integrate cryptocurrency into the game in a soft way. Also, he wants to do something unique and increase the involvement of his community. + +He chooses to use the Faterium platform, configures user profile and creates a community on the platform. Since his game has a very interesting plot and characters, he decides to create an asset for each key character in the game. Thanks to a user-friendly interface, he mints new assets in a short time. Then, with the help of the Faterium SDK, he adds these assets to the game as special rewards for players and announce the new feature on his social media. + +Then, he releases new story missions in the game, and players who have assets of their favorite characters, now can directly influence on how the game's story develops by spending assets and voting on various plot twists and character decisions. Players who love the story of the game now have cool tools to interact and influence the game, and last but not least, they can freely sell and buy these assets on decentralized marketplaces. + +It is important to note that game developers who already have own tokens or assets may not create a new one, but use an existing one by bridging it to the Faterium platform. + +### Ecosystem Fit + +The main goal of Polkadot is to create a decentralized network where users are in control. Faterium empowers as many people as possible to create safe, fair, universal voting polls on any topic possible. In addition, the Faterium platform will not focus only on its own Substrate Network - our main development goal is to cover as many Web3 networks as possible along with Web2. All this will help attract a lot of people who are not familiar with the crypto, influencers, other projects and games. That's why Polkadot and Faterium are compatible and can help each other make Web3 even more popular. + +## Team :busts_in_silhouette: + +### Legal Structure + +- **Registered Legal Entity:** DodoRare, Inc. +- **Registered Address:** 651 N Broad St Suite 206, Middletown, DE 19709. + +### Contact + +- **Contact Name:** David Knyshenko +- **Contact Email:** [info@dodorare.com](mailto:info@dodorare.com) +- **Website:** [dodorare.com](https://dodorare.com/) + +### Team members + +- [**David Knyshenko**](https://www.linkedin.com/in/david-knyshenko/), Blockchain/Fullstack Developer & Team Leader +- [**Oleksii Knyshenko**](https://www.linkedin.com/in/oleksii-knyshenko/), Rust Developer +- [**Daniil Anikin**](https://github.com/Heezay), Rust Developer +- [**Andrew Spodarenko**](https://www.behance.net/andrewspodarenko), UI/UX Designer +- [**Dariya Davydova**](https://www.artstation.com/keunhwajae), Digital Artist & Designer + +### Team's experience + +- [Crossbow](https://github.com/w3f/Grants-Program/pull/668) - Our second W3F grant to enhance and improve Mobile Game Framework: Cross-Platform build tools and toolkit for Rust and Substrate community. By [our team](https://github.com/dodorare). +- [Narnao Labyrinth](https://narnao.com/) - Our team has been working on this game project for more than a year. Some unique features originally from Narnao - now evolved into something bigger inside Faterium. The launch of the Narnao Labyrinth is tightly connected to the launch of Faterium, it will be a flagman project that will show most of the features and will initially bring the gamer community to Faterium. By [our team](https://dodorare.com/). +- Mobile Game Framework - Our first team Web3Foundation [grant](https://github.com/enfipy/Grants-Program/blob/master/applications/mobile-game-framework.md), mobile building tool. By [our team](https://github.com/dodorare). +- Substrate Atom and VSCode plugins - Have contributed some code to Web3Foundation Grant for Substrate [VSCode](https://github.com/everstake/vscode-plugin-substrate/graphs/contributors) and [Atom](https://github.com/everstake/atom-plugin-substrate/graphs/contributors) plugins while worked in outsource company. By [enfipy](https://github.com/enfipy). +- [Polkadot CosmosSDK Integration](https://github.com/adoriasoft/polkadot_cosmos_integration) - Also, contributed to another Web3Foundation Grant while worked in another outsource company. Built logic behind ABCI pallet and Substrate with Tendermint. By [enfipy](https://github.com/enfipy). + +### Team Code Repos + +Website Links: +- [faterium.com](https://faterium.com/) +- [dapp.faterium.com](https://dapp.faterium.com/) + +Github Organizations: +- [@dodorare](https://github.com/dodorare) +- [@faterium](https://github.com/faterium) + +Repositories: +- [faterium/faterium-node](https://github.com/faterium/faterium-node) +- [faterium/faterium-dapp](https://github.com/faterium/faterium-dapp) +- [faterium/faterium-server](https://github.com/faterium/faterium-server) + +GitHub accounts of developer team: +- https://github.com/enfipy +- https://github.com/olvyko +- https://github.com/Heezay + +## Development Roadmap :nut_and_bolt: + +### Overview + +* **Total Estimated Duration:** 7 weeks +* **Full-time equivalent (FTE):** 5 +* **Total Costs:** 30,000 USD + +### Milestone 1 — Crowdfunding Polls + +* **Estimated Duration:** 4 weeks +* **FTE:** 5 +* **Costs:** 17,000 USD + +The main goal of the `Milestone 1` is to create base functionality for `Crowdfunding Polls`. To make it possible - we will create Substrate Node that will contain basic template pallets, alongside with [Pallet Assets](https://github.com/paritytech/substrate/tree/master/frame/assets) (for creating assets), and [Pallet Scheduler](https://github.com/paritytech/substrate/tree/master/frame/scheduler) (for scheduling polls endings). Also, we will create a new Pallet called `Crowdfunding Polls Pallet`. + +To minimize storage on chain (as [polkassembly](https://github.com/Premiurly/polkassembly/blob/master/front-end/src/components/CreateTreasuryProposal/TreasuryProposalFormButton.tsx#L189) and Polkadot [do](https://wiki.polkadot.network/docs/learn-treasury#announcing-the-proposal)) - we will create a Golang server that will [embed](https://pkg.go.dev/github.com/ipfs/kubo/core/coreapi) [IPFS node](https://docs.ipfs.tech/reference/go/api/#go-embedded-client) and [PocketBase](https://pocketbase.io/docs/use-as-framework/) (or launch nearby in separate docker containers), to create the best User Experience and make it possible to store big media files as IPFS CID in database. To make it simple and straightforward in usage - we will launch test Substrate Network with our pallet on our servers, and create pages for creating Polls, and voting (with help of [polkadot{.js} extension](https://polkadot.js.org/extension/)). + +Please, see the Substrate API design of the Faterium Platform [above](#substrate-and-backend-api). + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | **License** | We will add Apache 2.0 Licenses to all repositories. | +| 0b. | **Documentation** | We will provide both **inline documentation** of the code and a **live demo**. | +| 0c. | **Testing Guide** | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | **Docker** | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | **Crowdfunding Polls Pallet** | As described above - we will create a Substrate Pallet for creating `Crowdfunding Polls`. | +| 2. | **Configure Substrate Node** | As described above - we will create a Substrate Node from template and integrate `Pallet Assets`, `Pallet Scheduler` and our `Pallet Crowdfunding Polls`. | +| 3. | **Faterium Server with PocketBase and IPFS** | As described above - we will create a Golang Server with API through PocketBase for uploading polls details in `IPFS Node`. | +| 4. | **Launch testnet Substrate network on the server** | As described above - we will setup and run Faterium test network on our servers to make sure that everything works as designed. | +| 5. | **Pages for creating Polls and voting on it** | As described above - we will create pages for creating and using `Crowdfunding Polls` to make sure that all functionality is working well. | + +### Milestone 2 — Profiles, Communities, and Pages + +* **Estimated Duration:** 3 weeks +* **FTE:** 5 +* **Costs:** 13,000 USD + +The main goal of the `Milestone 2` is to create UI design (see [wireframes](#wireframes) for the reference) and all main functionality of Faterium Platform: Communities, User Profiles, Categories, Assets, Crowdfunding Polls. After completion of `Milestone 1` - we will have Golang Server that we will extend with new functionality: wallet connect, user profile configuration, community creation, asset creation, voting. + +Please, see the Backend API design of the Faterium Platform [above](#substrate-and-backend-api). + +Also, we will prepare and publish and Article, that will explain a new concept of `Crowdfunding Polls`. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | **License** | We will add Apache 2.0 Licenses to all repositories. | +| 0b. | **Documentation** | We will provide both **inline documentation** of the code and a **live demo**. | +| 0c. | **Testing Guide** | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 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** that explains the concept of the Faterium Network, it's features, and usecases. More general-public-oriented version of what described in this application. | +| 1. | **Create design for Faterium dApp** | As described above - we will create a UI design for Faterium Platform. | +| 2. | **Extend Faterium server** | As described above - we will update and extend Faterium Server to make it work as designed. | +| 3. | **All web pages for dApp** | As described above - we will create all website pages from design and connect them to Faterium Server / Faterium Network node. | + +## Future Plans + +1. [IPFS Cluster](https://ipfscluster.io/) Integration. +2. DEX + Subsidizing System / Fuel-Gas Tanks. +3. Anti-spam System + Account Verification. +4. Author & Project Verification. +5. Faterium API & SDK. +6. Faterium Android and iOS Apps. +7. Faterium Discord and Telegram Bots. From bc7d7d9cf3129999fdb65116b3e8ed538a07d117 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Wed, 16 Nov 2022 14:58:06 +0100 Subject: [PATCH 021/959] Update accepted_grant_applications.md Add Faterium --- docs/accepted_grant_applications.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 06922e9f775..089a8763a7e 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -572,3 +572,4 @@ | [SubRelay](http://subrelay.xyz/) | SubRelay | [GitHub](https://github.com/subrelay) | ☐ | ☐ | ☐ | | [Wow Labz](http://www.wowlabz.com) | Dot Marketplace Phase 3 | [GitHub](https://github.com/orgs/WowLabz) | ☐ | ☐ | ☐ | | [10Clouds Sp. z o.o.](https://10clouds.com/) | Crowdloan Front End Template | [GitHub](https://github.com/10clouds) | ☐ | ☐ | ☐ | +| [DodoRare, Inc.](https://dodorare.com/) | Faterium | [GitHub](https://github.com/faterium) | ☐ | ☐ | ☐ | From 3bdcb48354045246a57caa16cb16f4b1e4a7dea5 Mon Sep 17 00:00:00 2001 From: Diogo <112647953+dsm-w3f@users.noreply.github.com> Date: Wed, 16 Nov 2022 16:45:57 -0300 Subject: [PATCH 022/959] Update accepted_grant_applications.md (#1278) --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 089a8763a7e..216fd4f3504 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -516,7 +516,7 @@ | [Lee](https://github.com/rust-0x0) | Hex Space Social Graph | [GitHub](https://github.com/rust-0x0) | ☐ | ☒ | ☐ | | [Liberland LLC](https://liberland.org/en/) | Liberland Pallets | [GitHub](https://github.com/liberland/liberland_substrate) | ☐ | ☐ | ☐ | | [Standard Protocol](https://standard.tech/) | Signac - a monorepo plugin for developing multiple Parity ink! smart contracts | [GitHub](https://github.com/standardweb3/signac) | ☐ | ☒ | ☒ | -| [B-Datagray](https://www.b-datagray.com/) | Datagen Project | [GitHub](https://github.com/Datagen-Project) | ☐ | ☐ | ☐ | +| [B-Datagray](https://www.b-datagray.com/) | Datagen Project | [GitHub](https://github.com/Datagen-Project) | ☐ | ☒ | ☐ | | [Colorful Notion](https://polkaholic.io/#chains) | Polkaholic.io's Multi-Chain Substrate Block Explorer | [GitHub](https://github.com/colorfulnotion/polkaholic/) | ☐ | ☐ | ☐ | | [Common Orbit LLC](https://brson.github.io) | `wasm-opt` for Rust | [GitHub](https://github.com/brson/wasm-opt-rs) | ☐ | ☒ | ☒ | | [Blockcoders](https://blockcoders.io/) | Ink Explorer | [GitHub](https://github.com/blockcoders) | ☐ | ☒ | ☐ | From 58c4f9e6e64c3ab9460363752af5c3aa6b1c4de9 Mon Sep 17 00:00:00 2001 From: Noc2 Date: Thu, 17 Nov 2022 15:57:27 +0100 Subject: [PATCH 023/959] remove open grants program --- docs/T&Cs.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/docs/T&Cs.md b/docs/T&Cs.md index f5fd49929a2..c3b87881c87 100644 --- a/docs/T&Cs.md +++ b/docs/T&Cs.md @@ -1,7 +1,7 @@ Grants Terms and Conditions =========================== -Updated July 2022 +Updated November 2022 * * * * * @@ -35,19 +35,19 @@ The terms defined in this section whenever used in these Terms and Conditions sh "Intellectual Property Rights" means any (i) patents, designs, copyright and related rights, database rights, trademarks, trade names (whether registered or unregistered), and the related rights to apply for registration thereof; (ii) applications, extensions and renewals in relation to any of these rights; (iii) know-how and confidential information; and (iv) all other rights of a similar nature and/or having an equivalent effect anywhere in the world; -"Milestones" mean any and all of the milestones specified in the final version of the application under Development Roadmap and approved by the Grants Committee in accordance with the Procedure as well as placed in the applications folder of the W3F Open Grants Program Repository at ; +"Milestones" mean any and all of the milestones specified in the final version of the application under Development Roadmap and approved by the Grants Committee in accordance with the Procedure as well as placed in the applications folder of the W3F Grants Program Repository at ; "Polkadot" means a scalable heterogeneous multi-chain framework developed by, or the development of which has been procured by Web 3.0. that has the features described in the white paper ("Polkadot: Vision For A Heterogeneous Multi-Chain Framework -- Draft 1") or as otherwise determined by Web 3.0. in its sole discretion from time to time) and utilizes DOTs as the blockchain token native to its operation and/or functioning; -"Procedure" means the procedure in connection with the Web 3.0 Foundation Open Grants Program, as established in Section 4 below; +"Procedure" means the procedure in connection with the Web 3.0 Foundation Grants Program, as established in Section 4 below; "Software" means the deliverables created by You during the development activities performed according to these Terms and Conditions in their final and working version, and that are to be provided to the Foundation in accordance with the Specifications, Milestones and Time Schedule; -"Specifications" mean the reasonably detailed technical and/or other requirements describing the features and functionality of the Software, as specified in the final version of the application approved by the Grants Committee in accordance with the Procedure and placed in the applications folder of the W3F Open Grants Program Repository at . +"Specifications" mean the reasonably detailed technical and/or other requirements describing the features and functionality of the Software, as specified in the final version of the application approved by the Grants Committee in accordance with the Procedure and placed in the applications folder of the W3F Grants Program Repository at . "Terms and Conditions" means this terms and conditions together with any documents referred to in it; -"Time Schedule" means the time schedule specified in the final version of the application approved by the Grants Committee in accordance with the Procedure and placed in the applications folder of the W3F Open Grants Program Repository at . +"Time Schedule" means the time schedule specified in the final version of the application approved by the Grants Committee in accordance with the Procedure and placed in the applications folder of the W3F Grants Program Repository at . ## 3. Eligibility @@ -71,7 +71,7 @@ You shall indemnify and hold harmless Web 3.0 from any third party claims (inclu ## 4. Procedure -To apply for the Web 3.0 Foundation Open Grants Program, your application shall fulfill the following criteria: +To apply for the Web 3.0 Foundation Grants Program, your application shall fulfill the following criteria: - it shall be a software-based project, which contributes to the advancement of the Polkadot ecosystem; - the total amount of funding requested for the project shall be below USD 30,000 and USD 100,000 for follow-up grants at the time of submission; @@ -79,17 +79,17 @@ To apply for the Web 3.0 Foundation Open Grants Program, your application shall - You must accept payment in the blockchain tokens native to the Bitcoin Network ("BTCs") or the Ethereum based stablecoin DAI; - You will need to submit the application and deliver the milestones according to the process specified below; -The open grants process consists of five parts, each of them described in more detail below: +The grants process consists of five parts, each of them described in more detail below: **(i) Grant application process:** -To apply for a grant of the Web 3.0 Foundation Open Grants Program, You shall comply with the procedures established in the README.md file under as well as the process defined inside this document. +To apply for a grant of the Web 3.0 Foundation Grants Program, You shall comply with the procedures established in the README.md file under as well as the process defined inside this document. -To apply for a grant of the Web3 Foundation Open Grants Program, the grantee needs to fork (= create a copy on GitHub of) the Open-Grants-Program GitHub repository. In the newly created fork (=copy on GitHub), the grantee has to create a copy of the application-template.md. The copied application-template.md needs to be renamed as "project_name.md". "Project_name" needs to be replaced with the name of the project application. Additionally, the grantee has to fill out all mandatory parts of the application-template.md presented in bold letters. Once the grantees have completed the application, they need to create a new pull request (= in this case, a mechanism to submit the changes of the fork to the original Open-Grants-Program GitHub repository) by clicking on the "create new pull request" button shown inside the fork of the W3F Open-Grants-Program GitHub repository. After this, the grantee needs to sign off the terms and conditions presented via the CLA assistant. +To apply for a grant of the Web3 Foundation Grants Program, the grantee needs to fork (= create a copy on GitHub of) the Open-Grants-Program GitHub repository. In the newly created fork (=copy on GitHub), the grantee has to create a copy of the application-template.md. The copied application-template.md needs to be renamed as "project_name.md". "Project_name" needs to be replaced with the name of the project application. Additionally, the grantee has to fill out all mandatory parts of the application-template.md presented in bold letters. Once the grantees have completed the application, they need to create a new pull request (= in this case, a mechanism to submit the changes of the fork to the original Open-Grants-Program GitHub repository) by clicking on the "create new pull request" button shown inside the fork of the W3F Open-Grants-Program GitHub repository. After this, the grantee needs to sign off the terms and conditions presented via the CLA assistant. **(ii) Application review process:** -The Web 3.0 grants committee, which is specified on the [Open-Grants-Program GitHub repository ](https://github.com/w3f/Grants-Program)(the "Grants Committee"), can issue comments and request changes on the grant application pull request (the submission of the grant application on GitHub). As soon as 1/3 of the Grants Committee approves the pull request, the terms and conditions are signed off and all requested changes are addressed, the application is officially accepted. The application is now a part of the [W3F Open-Grants-Program GitHub repository](https://github.com/w3f/Grants-Program). The time point of the acceptance by the Grants Committee is hereby stored on GitHub and counts as the official beginning of the grant. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party. The final version approved by the Grants Committee of the Specifications, the Time Schedule and Milestones will be placed in the applications folder of the W3F Open Grants Program Repository at via the merge function of GitHub. +The Web 3.0 grants committee, which is specified on the [Open-Grants-Program GitHub repository ](https://github.com/w3f/Grants-Program)(the "Grants Committee"), can issue comments and request changes on the grant application pull request (the submission of the grant application on GitHub). As soon as 1/3 of the Grants Committee approves the pull request, the terms and conditions are signed off and all requested changes are addressed, the application is officially accepted. The application is now a part of the [W3F Open-Grants-Program GitHub repository](https://github.com/w3f/Grants-Program). The time point of the acceptance by the Grants Committee is hereby stored on GitHub and counts as the official beginning of the grant. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party. The final version approved by the Grants Committee of the Specifications, the Time Schedule and Milestones will be placed in the applications folder of the W3F Grants Program Repository at via the merge function of GitHub. **(iii) Milestone delivery process:** @@ -162,7 +162,7 @@ The Parties acknowledge and agree that the requirements set out in the Milestone ## 7. Terms of Grant Giving -Web 3.0. shall grant You, as compensation for the delivery of the Software and the related deliverables and the grant of license rights on the Intellectual Property Rights to the Web 3.0., a Grant as indicated in the application placed in the applications folder of the W3F Open Grants Program Repository at . +Web 3.0. shall grant You, as compensation for the delivery of the Software and the related deliverables and the grant of license rights on the Intellectual Property Rights to the Web 3.0., a Grant as indicated in the application placed in the applications folder of the W3F Grants Program Repository at . The Parties agree that the Grant is a lump-sum payment and that no additional compensation is due for the actual development costs incurred. From 02c5b18d4aa9d0cffd87d31f6284b74094e18915 Mon Sep 17 00:00:00 2001 From: Noc2 Date: Thu, 17 Nov 2022 16:00:22 +0100 Subject: [PATCH 024/959] remove open grants program part 2 --- docs/T&Cs.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/docs/T&Cs.md b/docs/T&Cs.md index c3b87881c87..394a8444aa3 100644 --- a/docs/T&Cs.md +++ b/docs/T&Cs.md @@ -85,11 +85,11 @@ The grants process consists of five parts, each of them described in more detail To apply for a grant of the Web 3.0 Foundation Grants Program, You shall comply with the procedures established in the README.md file under as well as the process defined inside this document. -To apply for a grant of the Web3 Foundation Grants Program, the grantee needs to fork (= create a copy on GitHub of) the Open-Grants-Program GitHub repository. In the newly created fork (=copy on GitHub), the grantee has to create a copy of the application-template.md. The copied application-template.md needs to be renamed as "project_name.md". "Project_name" needs to be replaced with the name of the project application. Additionally, the grantee has to fill out all mandatory parts of the application-template.md presented in bold letters. Once the grantees have completed the application, they need to create a new pull request (= in this case, a mechanism to submit the changes of the fork to the original Open-Grants-Program GitHub repository) by clicking on the "create new pull request" button shown inside the fork of the W3F Open-Grants-Program GitHub repository. After this, the grantee needs to sign off the terms and conditions presented via the CLA assistant. +To apply for a grant of the Web3 Foundation Grants Program, the grantee needs to fork (= create a copy on GitHub of) the Grants-Program GitHub repository. In the newly created fork (=copy on GitHub), the grantee has to create a copy of the application-template.md. The copied application-template.md needs to be renamed as "project_name.md". "Project_name" needs to be replaced with the name of the project application. Additionally, the grantee has to fill out all mandatory parts of the application-template.md presented in bold letters. Once the grantees have completed the application, they need to create a new pull request (= in this case, a mechanism to submit the changes of the fork to the original Grants-Program GitHub repository) by clicking on the "create new pull request" button shown inside the fork of the W3F Grants-Program GitHub repository. After this, the grantee needs to sign off the terms and conditions presented via the CLA assistant. **(ii) Application review process:** -The Web 3.0 grants committee, which is specified on the [Open-Grants-Program GitHub repository ](https://github.com/w3f/Grants-Program)(the "Grants Committee"), can issue comments and request changes on the grant application pull request (the submission of the grant application on GitHub). As soon as 1/3 of the Grants Committee approves the pull request, the terms and conditions are signed off and all requested changes are addressed, the application is officially accepted. The application is now a part of the [W3F Open-Grants-Program GitHub repository](https://github.com/w3f/Grants-Program). The time point of the acceptance by the Grants Committee is hereby stored on GitHub and counts as the official beginning of the grant. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party. The final version approved by the Grants Committee of the Specifications, the Time Schedule and Milestones will be placed in the applications folder of the W3F Grants Program Repository at via the merge function of GitHub. +The Web 3.0 grants committee, which is specified on the [Grants-Program GitHub repository ](https://github.com/w3f/Grants-Program)(the "Grants Committee"), can issue comments and request changes on the grant application pull request (the submission of the grant application on GitHub). As soon as 1/3 of the Grants Committee approves the pull request, the terms and conditions are signed off and all requested changes are addressed, the application is officially accepted. The application is now a part of the [W3F Grants-Program GitHub repository](https://github.com/w3f/Grants-Program). The time point of the acceptance by the Grants Committee is hereby stored on GitHub and counts as the official beginning of the grant. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party. The final version approved by the Grants Committee of the Specifications, the Time Schedule and Milestones will be placed in the applications folder of the W3F Grants Program Repository at via the merge function of GitHub. **(iii) Milestone delivery process:** @@ -97,7 +97,7 @@ To submit one of the possible multiple milestones specified in the application, **(iv) Milestone review process:** -The Grants Evaluators, who are specified on the [Open-Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), can issue comments and request changes on the milestone delivery pull request. +The Grants Evaluators, who are specified on the [Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), can issue comments and request changes on the milestone delivery pull request. a) Purpose and object of the milestone review process @@ -124,7 +124,7 @@ As soon as one evaluator approves the pull request, the delivery is officially a **(v) Payment process:** -The Operations Team specified in the [Open-Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), gets notified once the above-specified delivery was accepted or after 2 weeks without any feedback after the initial delivery. As soon as any feedback is provided by the evaluators, this feedback first needs to be resolved. After this, the Operations Team makes the payment to the BTC or Ethereum address specified in the initial application. +The Operations Team specified in the [Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), gets notified once the above-specified delivery was accepted or after 2 weeks without any feedback after the initial delivery. As soon as any feedback is provided by the evaluators, this feedback first needs to be resolved. After this, the Operations Team makes the payment to the BTC or Ethereum address specified in the initial application. ## 5. Scope of these Terms and Conditions @@ -240,13 +240,19 @@ These Terms and Conditions and any documents referred to in it shall constitute The headings used herein are inserted only as a matter of convenience and for reference only. They shall not affect the construction or interpretation of these Terms and Conditions. -## 13. Applicable Law and Jurisdiction +## 13. Referral Program + +if You were referred to the Web 3.0 Foundation Grants Program by a person who is either a Polkadot Ambassador or, in any case, a person considered by Web 3.0 as being active in the Polkadot Ecosystem (a “Valid Referee”), upon signature of this Terms and Conditions you could indicate to Web 3.0 the name of this Valid Referee, provided that he/she gave you his/her consent to share his/her identity with Web 3.0. Web 3.0, as part of its grant referral program, will grant to the Valid Referee a referral bonus of the amount at that time allocated as bonus under such program. +For the avoidance of any doubt, Web 3.0 reserves the right to decide - at its complete discretion - if an individual is (and/or continues to be) a Valid Referee, and only in this case the referee will be entitled to receive the referral bonus. + + +## 14. Applicable Law and Jurisdiction These Terms and Conditions shall be governed by and construed in accordance with the substantive laws of Switzerland without any reference to its conflict of law provisions. The provisions of the United Nation Convention on contracts for the International Sale of Goods (CISG) shall not apply. Any disputes arising out of or in connection with these terms and conditions and contracts entered into thereunder shall be submitted to the sole and exclusive jurisdiction of the courts of the city of Zug. -## 14. Polkadot Network +## 15. Polkadot Network If You are using Polkadot network for the purpose of the software development, research and/or the production of software documentation and technical education material You agree to be bound by specific term as follows: From aaafcae2fd07d4dea55fc3473da967a7755a0d43 Mon Sep 17 00:00:00 2001 From: Noc2 Date: Thu, 17 Nov 2022 16:21:35 +0100 Subject: [PATCH 025/959] Update T&Cs --- docs/T&Cs.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/docs/T&Cs.md b/docs/T&Cs.md index 394a8444aa3..f02d678ec3b 100644 --- a/docs/T&Cs.md +++ b/docs/T&Cs.md @@ -73,10 +73,9 @@ You shall indemnify and hold harmless Web 3.0 from any third party claims (inclu To apply for the Web 3.0 Foundation Grants Program, your application shall fulfill the following criteria: -- it shall be a software-based project, which contributes to the advancement of the Polkadot ecosystem; -- the total amount of funding requested for the project shall be below USD 30,000 and USD 100,000 for follow-up grants at the time of submission; +- it shall be a research or software-based project, which contributes to the advancement of the Polkadot ecosystem; - the Software shall be released under the Apache license version 2.0.; -- You must accept payment in the blockchain tokens native to the Bitcoin Network ("BTCs") or the Ethereum based stablecoin DAI; +- You must accept payment in Bitcoin, USDT (on Kusama or Ethereum), USDC/DAI (Ethereum) or aUSD (Acala); - You will need to submit the application and deliver the milestones according to the process specified below; The grants process consists of five parts, each of them described in more detail below: @@ -89,7 +88,7 @@ To apply for a grant of the Web3 Foundation Grants Program, the grantee needs to **(ii) Application review process:** -The Web 3.0 grants committee, which is specified on the [Grants-Program GitHub repository ](https://github.com/w3f/Grants-Program)(the "Grants Committee"), can issue comments and request changes on the grant application pull request (the submission of the grant application on GitHub). As soon as 1/3 of the Grants Committee approves the pull request, the terms and conditions are signed off and all requested changes are addressed, the application is officially accepted. The application is now a part of the [W3F Grants-Program GitHub repository](https://github.com/w3f/Grants-Program). The time point of the acceptance by the Grants Committee is hereby stored on GitHub and counts as the official beginning of the grant. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party. The final version approved by the Grants Committee of the Specifications, the Time Schedule and Milestones will be placed in the applications folder of the W3F Grants Program Repository at via the merge function of GitHub. +The Web 3.0 grants committee, which is specified on the [Grants-Program GitHub repository ](https://github.com/w3f/Grants-Program)(the "Grants Committee"), can issue comments and request changes on the grant application pull request (the submission of the grant application on GitHub). As soon enough members of the Grants Committee approve the pull request, the terms and conditions are signed off and all requested changes are addressed, the application is officially accepted. The application is now a part of the [W3F Grants-Program GitHub repository](https://github.com/w3f/Grants-Program). The time point of the acceptance by the Grants Committee is hereby stored on GitHub and counts as the official beginning of the grant. The original submission is stored with a unique commit hash (identifier) and can not be altered by any party. The final version approved by the Grants Committee of the Specifications, the Time Schedule and Milestones will be placed in the applications folder of the W3F Grants Program Repository at via the merge function of GitHub. **(iii) Milestone delivery process:** @@ -124,8 +123,7 @@ As soon as one evaluator approves the pull request, the delivery is officially a **(v) Payment process:** -The Operations Team specified in the [Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), gets notified once the above-specified delivery was accepted or after 2 weeks without any feedback after the initial delivery. As soon as any feedback is provided by the evaluators, this feedback first needs to be resolved. After this, the Operations Team makes the payment to the BTC or Ethereum address specified in the initial application. - +The Operations Team specified in the [Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), gets notified once the above-specified delivery was accepted or after 2 weeks without any feedback after the initial delivery. As soon as any feedback is provided by the evaluators, this feedback first needs to be resolved. After this, the Operations Team makes the payment to the Bitcoin, USDT (on Kusama or Ethereum), USDC/DAI (Ethereum) or aUSD (Acala) address specified in the initial application. ## 5. Scope of these Terms and Conditions The subject matter of these Terms and Conditions is (i) the development of the Software by You in accordance with the Specifications, Milestones and Time Schedule, as well as any related activities (including any development activities undertaken before the Effective Date in relation to the Software) (collectively referred to as "Development Work") in accordance with the terms of these Terms and Conditions. @@ -160,6 +158,8 @@ The Parties acknowledge and agree that the requirements set out in the Milestone 6. You agree to forbear from making any public or non-confidential statement with respect to any claim or complaint against the Foundation without having obtained the Foundation’s prior written consent. +7. You agree that during the term of this agreement together with the Schedules (or any of each SOW), including extensions or modifications thereto, and for a period of nine (9) months thereafter, neither Grantee nor the Foundation will recruit, directly or indirectly hire, solicit or employ, engage as an independent contractor, any employee or independent contractor of either party, or any employee or independent contractor of any of the other subcontractors, who are involved in the development, use, or provision of the Services, without the prior written approval of the party whose employee or independent contractor is being considered for employment or engagement as an independent contractor, except as otherwise required by law. If one of the parties breaches this section, this party shall pay forty thousand dollars ($40,000.00) for each person hired as liquidated damages. The parties agree that quantifying losses arising from breach of this section is inherently difficult and stipulate that the agreed upon sum is not a penalty, but rather a reasonable measure of damages, based upon the parties’ experience in the software development industry and given the nature of the losses that may result from such breach. + ## 7. Terms of Grant Giving Web 3.0. shall grant You, as compensation for the delivery of the Software and the related deliverables and the grant of license rights on the Intellectual Property Rights to the Web 3.0., a Grant as indicated in the application placed in the applications folder of the W3F Grants Program Repository at . @@ -188,7 +188,9 @@ You hereby warrant that: (c) there are no licenses or rights current in effect in favor of any third party to use the Software and the related deliverables which would impair the rights granted to Web 3.0. as provided for under these Terms and Conditions; and -1. there is no pending or threatened claim, action, suit, investigation or proceeding of any kind challenging, alleging or asserting that the Software and the related deliverables were improperly or invalidly granted or are otherwise not protected as Intellectual Property Rights. +(d) You have disclosed all previous involvement of any team member in the Web 3.0 grant process, including, but not limited to: Closed, Rejected, Accepted, Delivered and Pending grant applications. + +(e) there is no pending or threatened claim, action, suit, investigation or proceeding of any kind challenging, alleging or asserting that the Software and the related deliverables were improperly or invalidly granted or are otherwise not protected as Intellectual Property Rights. You further warrant that the Software and the related deliverables: @@ -242,7 +244,7 @@ The headings used herein are inserted only as a matter of convenience and for re ## 13. Referral Program -if You were referred to the Web 3.0 Foundation Grants Program by a person who is either a Polkadot Ambassador or, in any case, a person considered by Web 3.0 as being active in the Polkadot Ecosystem (a “Valid Referee”), upon signature of this Terms and Conditions you could indicate to Web 3.0 the name of this Valid Referee, provided that he/she gave you his/her consent to share his/her identity with Web 3.0. Web 3.0, as part of its grant referral program, will grant to the Valid Referee a referral bonus of the amount at that time allocated as bonus under such program. +If you were referred to the Web 3.0 Foundation Grants Program by a person who is either a Polkadot Ambassador or, in any case, a person considered by Web 3.0 as being active in the Polkadot Ecosystem (a “Valid Referee”), upon signature of this Terms and Conditions you could indicate to Web 3.0 the name of this Valid Referee, provided that he/she gave you his/her consent to share his/her identity with Web 3.0. Web 3.0, as part of its grant referral program, will grant to the Valid Referee a referral bonus of the amount at that time allocated as bonus under such program. For the avoidance of any doubt, Web 3.0 reserves the right to decide - at its complete discretion - if an individual is (and/or continues to be) a Valid Referee, and only in this case the referee will be entitled to receive the referral bonus. From ab1fd62e0d50ff5df9aa54ad0dadfbe34557d3e7 Mon Sep 17 00:00:00 2001 From: Noc2 Date: Thu, 17 Nov 2022 16:23:43 +0100 Subject: [PATCH 026/959] T&C update --- docs/T&Cs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/T&Cs.md b/docs/T&Cs.md index f02d678ec3b..3d0fb38d509 100644 --- a/docs/T&Cs.md +++ b/docs/T&Cs.md @@ -9,7 +9,7 @@ By participating you acknowledge and accept the​ terms and conditions​ of th * * * * * -These Terms and Conditions are entered into by and between the Web 3.0 Technologies Foundation, Baarerstrasse 14,6300 Zug, Switzerland (CHE-332.596.347) (henceforth "Web 3.0" or "We") and you as an applicant for the technical grant for software development, research and/or the production of software documentation and technical education material as specified in Guidelines for technical grant of Web 3.0 Technologies Foundation (henceforth "User" or "You") (each also a "Party" and together the "Parties"). Please read these Terms and Conditions carefully. By signing off the terms and conditions via the CLA assistant, You confirm that You have read these Terms and Conditions and that You agree to be bound by them. +These Terms and Conditions are entered into by and between the Web 3.0 Technologies Foundation, Baarerstrasse 14, 6300 Zug, Switzerland (CHE-332.596.347) (henceforth "Web 3.0" or "We") and you as an applicant for the technical grant for software development, research and/or the production of software documentation and technical education material as specified in Guidelines for technical grant of Web 3.0 Technologies Foundation (henceforth "User" or "You") (each also a "Party" and together the "Parties"). Please read these Terms and Conditions carefully. By signing off the terms and conditions via the CLA assistant, You confirm that You have read these Terms and Conditions and that You agree to be bound by them. We reserve the right to change, modify, add or remove portions of these Terms and Conditions from time to time. If this occurs, We will notify You in adequate form on such updates. From 963cf5320896bf3e2d8fc57e2fd90fd52697d3a1 Mon Sep 17 00:00:00 2001 From: Noc2 Date: Thu, 17 Nov 2022 16:26:08 +0100 Subject: [PATCH 027/959] remove payment without feedback --- docs/T&Cs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/T&Cs.md b/docs/T&Cs.md index 3d0fb38d509..05773589b19 100644 --- a/docs/T&Cs.md +++ b/docs/T&Cs.md @@ -123,7 +123,7 @@ As soon as one evaluator approves the pull request, the delivery is officially a **(v) Payment process:** -The Operations Team specified in the [Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), gets notified once the above-specified delivery was accepted or after 2 weeks without any feedback after the initial delivery. As soon as any feedback is provided by the evaluators, this feedback first needs to be resolved. After this, the Operations Team makes the payment to the Bitcoin, USDT (on Kusama or Ethereum), USDC/DAI (Ethereum) or aUSD (Acala) address specified in the initial application. +The Operations Team specified in the [Grants-Program GitHub repository](https://github.com/w3f/Grants-Program), gets notified once the above-specified delivery was accepted. As soon as any feedback is provided by the evaluators, this feedback first needs to be resolved. After this, the Operations Team makes the payment to the Bitcoin, USDT (on Kusama or Ethereum), USDC/DAI (Ethereum) or aUSD (Acala) address specified in the initial application. ## 5. Scope of these Terms and Conditions The subject matter of these Terms and Conditions is (i) the development of the Software by You in accordance with the Specifications, Milestones and Time Schedule, as well as any related activities (including any development activities undertaken before the Effective Date in relation to the Software) (collectively referred to as "Development Work") in accordance with the terms of these Terms and Conditions. From 041bf9441b3a4c93e308c83da2afaf5dbbc9d7fd Mon Sep 17 00:00:00 2001 From: David Hawig Date: Fri, 18 Nov 2022 08:03:20 +0100 Subject: [PATCH 028/959] Referral program (#1248) * Update README.md Start working on the referral program * Update README.md initial draft * Update application-template.md * Update README.md update text * Update README.md Co-authored-by: Aleixo Sanchez <15819210+alxs@users.noreply.github.com> * Update README.md Co-authored-by: Aleixo Sanchez <15819210+alxs@users.noreply.github.com> * Update applications/application-template.md Co-authored-by: S E R A Y A * Update application-template.md Move Referral to the end * Update README.md Update to 500 USD to make it initially easier * Update applications/application-template.md Co-authored-by: S E R A Y A Co-authored-by: Aleixo Sanchez <15819210+alxs@users.noreply.github.com> Co-authored-by: S E R A Y A --- README.md | 7 +++++++ applications/application-template.md | 5 +++++ 2 files changed, 12 insertions(+) diff --git a/README.md b/README.md index c26f5001e86..c65c962e0a8 100644 --- a/README.md +++ b/README.md @@ -18,6 +18,7 @@ - [Changes to a Grant after Approval](#changes-to-a-grant-after-approval) - [:mailbox_with_mail: Suggest a Project](#mailbox_with_mail-suggest-a-project) - [:hammer_and_wrench: Maintenance Grants](#hammer_and_wrench-maintenance-grants) +- [:moneybag: Referral Program](#moneybag-referral-program) - [:bulb: Help](#bulb-help) - [Additional information](#additional-information) - [Real-time conversation](#real-time-conversation) @@ -217,6 +218,12 @@ Please note that: - Please bear in mind that the Grants Committee might be stricter in accepting maintainers when compared to typical grants, mostly selecting for applicants with proven experience in the relevant tech stacks. - Maintenance Grants are only awarded for fixed timeframes. The requested duration needs to be specified in the application. +## :moneybag: Referral Program + +We give away 500 USD to each referral of a successful grant application by _anyone having previously worked on a Web3 Foundation grant_ or _a [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors)_. Web3 Foundation and Parity employees do not qualify for the program, even if they previously worked on a grant. + +In order to be eligible for the referral bonus, the application itself must contain the name of the [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors) or the GitHub account of the grantee as well as the payment address for the referral bonus (see the [application template](applications/application-template.md)). Payment is made in Bitcoin, USDT (on Kusama or Ethereum), USDC/DAI (Ethereum) or aUSD (Acala). + ## :bulb: Help ### Additional information diff --git a/applications/application-template.md b/applications/application-template.md index f7fb24f76c9..8d6c2b00b51 100644 --- a/applications/application-template.md +++ b/applications/application-template.md @@ -155,6 +155,11 @@ Please include here - how you intend to use, enhance, promote and support your project in the short term, and - the team's long-term plans and intentions in relation to it. +## Referral Program (optional) :moneybag: + +You can find more information about the program [here](../README.md#moneybag-referral-program). +- **Referrer:** Name of the Polkadot Ambassador or GitHub account of the Web3 Foundation grantee +- **Payment Address:** BTC, Ethereum (USDT/USDC/DAI) or Polkadot/Kusama (aUSD) payment address. Please also specify the currency. (e.g. 0x8920... (DAI)) ## Additional Information :heavy_plus_sign: From bf6c74f3d9e3ddc291cf07b5eb9f86eb3f457a61 Mon Sep 17 00:00:00 2001 From: random-ham <112565780+random-ham@users.noreply.github.com> Date: Fri, 18 Nov 2022 02:12:13 -0500 Subject: [PATCH 029/959] pallet-drand-client application (#1271) --- applications/pallet-drand-client.md | 159 ++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 applications/pallet-drand-client.md diff --git a/applications/pallet-drand-client.md b/applications/pallet-drand-client.md new file mode 100644 index 00000000000..fd200afe450 --- /dev/null +++ b/applications/pallet-drand-client.md @@ -0,0 +1,159 @@ +# drand in substrate + +- **Team Name:** The Bacon Beacon +- **Payment Address:** USDC 0x1C9e0bcA759e5Ec09246f4795310789b12F65a59 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +We are planning to integrate the [drand](https://drand.love/developer/) client into substrate. + +### Overview + +Current sources of verifiable randomness in Substrate are limited, and developers need to rely on deriving randomness themselves, or by taking it from BABE. + +The clear disadvantage of deriving randomness by the application developers is that all information on the blockchain is public. Resultingly, randomness is more likely to be predictable and gameable, especially on standalone Substrate chains. + +On the other hand, BABE provides two sources of randomness: public and private. +Public randomness is derivied once per epoch, and is easily verifiable by hashing all the VRF outputs from the previous epoch. Unfortunately, it is only computed once per epoch. +Private randomness is computed by each validator in secret to determine when they'd produce blocks. It is published with each block, which is as often as is possible on a blockchain and is provably verifiable and secure. Unfortunately, the random values that the validators publish are known to these validators *hours* in advance. + +Both of the above mentioned sources are internal: the randomness is derived from information *within* the network. +Another approach is to take randomness from an external source, if that source can be proven to be secure. + +One such source is [drand](https://drand.love/about/) (decentralised randomness beacon), which allows the participants "to produce collective, publicly verifiable, unbiased, unpredictable random values at fixed intervals". + +In this project, we want to enable any Substrate project to consume publically, verifiable randomness from drand. + +### Project Details + +Randomness needs to be retrieved from an HTTP API via a provider, which is itself either a member of the drand network, or a broadcaster of the randomness. +In either case, the pallet doesn't trust the provider blindly - instead, it can cryptographically verify the correctness of the randomness retrieved, by verifying it against the drand [chain randomness information](https://drand.love/developer/http-api/#chain-hash-info) contained in the Runtime. This chain intormation contains the network's well-known threshold public key, fixed interval for randomness generation, genesis time, and an initial random hash. + +This chain randomness information and an optional [round](https://drand.love/developer/http-api/#chain-hash-public-round) 'checkpoint' can be set in the chain's `GenesisConfig`, allowing the network to immediately start using the randomness from the first block. If appropriate, the pallet can also contain a `UpdateOrigin` `Config` parameter, allowing the the beacon source to be modified by a trusted authority (eg. Council, Sudo, whitelisted account, etc) without a runtime update. Each round will be obtained via HTTP API calls made via an off-chain worker, and each round will be verified for cryptographic accuracy and timeliness before being consumable by the runtime. + +### Ecosystem Fit + +Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions: + +- Where and how does your project fit into the ecosystem? + +A: It will be a Substrate pallet, likely with one of the standardized randomness trait interface in it's `Config`, allowing it to be easily plugged into other pallets. It will also contain a standalone Substrate chain with the pallet, demonstraiting some concrete examples of how it can be used. + +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? + +A: Parachains and standalone Substrate chains, dapps (especially ones using ZKPs), and anyone wanting to consume public randomness. + +- What need(s) does your project meet? + +A: Providing verifiable, public randomness. + +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? + +A: Not that we're aware of. + +## Team :busts_in_silhouette: + +### Team members + +- Bacon +- Ham + +### Contact + +- **Contact Name:** Bacon +- **Contact Email:** bacon.randomness.beacon@pm.me +- **Website:** N/A + +- **Contact Name:** Ham +- **Contact Method:** Github issues/discussion or Session ID `05947ccb461b7e693282c71afea61ebe81e52abe8b99e03901d6e6c9af06f9ac51` +- **Website:** N/A + +### Legal Structure + +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A + +### Team's experience + +Both team members have practical experience in developing cryptographic protocols (3 years combined) and Rust (4 years combined). We have completed the basic substrate tutorials for the purpose of preparing for this project. Apart from this information, we would like to keep the team's profiles private. +We believe that the quality of the project delivery will bear witness to our claims. + +### Team Code Repos + +- https://github.com/random-bacon + + +## Development Status :open_book: + +The public docs from [drand](https://drand.love/) serve best as technical introduction to what drand is, and how it can be integrated into existing projects. We will also use Github's Projects feature or Issues to create a backlog and task our progress publically. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 1 FTE (2 x half-time) +- **Total Costs:** 28,000 USD + +### Milestone 1: Create a Rust client library for drand + +While there exists one [drand Rust client library](https://github.com/iprs-dev/drand-rs), it hasn't been updated in 2 years. + +We will create a new Rust library that +- includes `no_std` support +- complies and works with the APIs outlined [here](https://github.com/drand/drand-client#api) +- verifies the cryptogrpahic randomness +- uses up-to-date dependencies +- has a set of tests for asserting proper functionality and reducing bugs from future updates + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 14,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| 0b. | Documentation | We will provide **inline documentation** alongside the code, a README explaining how it can be used, and a few examples demonstrating it's concrete usage. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. We will use standardized testing methods so tests can be pragmatically executed and updated by anyone. | +| 1. | Drand client library | We will build out a drand client library with the requirements mentioned in the Milestoke 1 overview. + +### Milestoke 2: Build a Substrate pallet with a fully-featured/configured example chain + +We will write a Substrate pallet that: +- implements the drand client library from Milestone 1 +- allows for the configuration and modification of the drand chain randomness information +- utilized off-chain workers to fetch round information, and ensuring validator consensus about it +- verifies the round information for cryptographic accuracy and timeliness +- provides a pragmatic way for other pallets to source the randomness + +We will also build an example Substrate node that: +- demonstrates a fully configured pallet-drand-client +- demonstrates an example pallet utilizing all of its features + +- **Estimated Duration:** 1 month +- **FTE:** 1 +- **Costs:** 14,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| 0b. | Documentation | We will create **dedicated documentation in the repo** of how to use the code and a basic **tutorial** that explains how a user can (example) spin up one of the Substrate nodes and interact with the chain in a way that utilized drand's randomness. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Example pallet | We will create a pallet that integrates the drand client library from Milestone 1, and write a sample pallet that uses its features (eg. return a message from a list of messages at random, based on the public randomness it retrieves via the API). +| 2. | Randomness verification | The pallet will be able to verify round randomness via the chain randomness information. +| 2. | Example chain | We spin up a testing chain to demonstrate how such a pallet works. + + +## Future Plans + +Once randomness is available to Substrate developers, we would be interested to write a client that actually *participates* in the drand protocol. +It may make sense for a common-good parachain to participate as a member of [League of Entropy](https://en.wikipedia.org/wiki/League_of_entropy). +We recognize the lack of accountability and other issues that can arise with an anonymous team maintaining such an important and foundational ecosystem component like a common-good parachain,, and we are open to discussion solutions relating to the development and maintenance of it. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** https://medium.com/web3foundation/web3-foundation-grants-program-reaches-400-projects-milestone-1k-grant-applications-received-93a7d3a5f942 + +Thank you for your time. We're looking forward to discussing this project with you. From bd146adbcb4f15f0b2ca46f5c230c946708dae45 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Fri, 18 Nov 2022 08:14:24 +0100 Subject: [PATCH 030/959] Update accepted_grant_applications.md Add Pallet Drand Client --- docs/accepted_grant_applications.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index 216fd4f3504..eeb4da07673 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -573,3 +573,4 @@ | [Wow Labz](http://www.wowlabz.com) | Dot Marketplace Phase 3 | [GitHub](https://github.com/orgs/WowLabz) | ☐ | ☐ | ☐ | | [10Clouds Sp. z o.o.](https://10clouds.com/) | Crowdloan Front End Template | [GitHub](https://github.com/10clouds) | ☐ | ☐ | ☐ | | [DodoRare, Inc.](https://dodorare.com/) | Faterium | [GitHub](https://github.com/faterium) | ☐ | ☐ | ☐ | +| [The Bacon Beacon](https://github.com/random-bacon) | Pallet Drand Client | [GitHub](https://github.com/random-bacon) | ☐ | ☐ | ☐ | From d2e606fae53a39e0688ecbb1287df8f99c0e0950 Mon Sep 17 00:00:00 2001 From: Kutsal Kaan Bilgin Date: Fri, 18 Nov 2022 10:18:01 +0300 Subject: [PATCH 031/959] ChainViz v1 application. (#1254) --- applications/chainviz.md | 317 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 317 insertions(+) create mode 100644 applications/chainviz.md diff --git a/applications/chainviz.md b/applications/chainviz.md new file mode 100644 index 00000000000..90d2f235a54 --- /dev/null +++ b/applications/chainviz.md @@ -0,0 +1,317 @@ +# ChainViz v1 + +- **Team Name:** Helikon Labs +- **Payment Address:** `bc1qxjy7sw0ffvpq86t6hj3mmqhnfz2hxt6pk7zdz0` (BTC) +- **Level:** 🐤 2 + +## Project Overview :page_facing_up: + +### Overview + +ChainViz Alpha web application, available at [alpha.chainviz.app](https://alpha.chainviz.app), is an [open-source](https://github.com/helikon-labs/chainviz) real-time 3D visualization of the Kusama relay chain block production process. + +![](https://raw.githubusercontent.com/helikon-labs/chainviz/development/readme_files/screenshot_01.png) + +Application in its current alpha version provides the following features: + +- Real-time 3D visualization of: + - Active validators, including paravalidation indication + - Block production by validators + - Block finalization +- Navigation of the 3D scene through zooming, panning and rotation +- Network status display +- Active validator list and search over identity/address +- Validator details panel upon click on a validator in the 3D model, or the validator list + +**This application is to fund the building of the first major version of ChainViz**, with the following features/visualizations: + +- Complete rebuild of the the existing functionality with improved UI/UX and WebGL models, shaders and animations +- Additional support for Polkadot +- New visualizations + - Parachains + - Assigned paravalidators + - XCM messages between parachains, or from parachains to relay chains + - Block content + - Author + - Extrinsics and arguments + - Events and arguments + +With these additional features, ChainViz is going to become a **complete real-time visualization** of the Polkadot and Kusama relay chains and their parachains. + +### Project Details + +#### Organization + +ChainViz v1 upgrade is a collaboration between [Helikon Labs](https://helikon.io) and [Klad](https://klad.design), carried out under the management of Helikon Labs. + +#### System Architecture + +##### Current System + +ChainViz Alpha currently utilizes [SubVT backend services](https://github.com/helikon-labs/subvt-backend) and Polkadot JS API as follows. + +- SubVT active validator list [service](https://github.com/helikon-labs/subvt-backend/tree/development/subvt-validator-list-server) + - List of all active validators + - For each validator, a summary including: + - Identity + - Validator preferences + - Self stake + - Nomination count and total amount, + - 1KV data if exists + - and more +- SubVT network status [service](https://github.com/helikon-labs/subvt-backend/tree/development/subvt-network-status-server) + - Era index + - Era reward points + - Total, minimum, maximum and average stake amounts +- Polkadot JS API + - Finalized block header subscription + - Utilized to mark finalized blocks + - Best block header subscription + - Utilized to display the block production animation + - Identify uncle blocks and visualize them + +Current ChainViz Alpha system architecture can be illustrated as follows. + +

+ +
+ Figure 1 ChainViz Alpha system architecture +

+ +##### Proposed Upgrade + +Proposed upgrade to the first major version requires the following additional data: + +- Block details + - Extrinsic list and parameters + - XCM messages (`XcmPallet` extrinsics) + - Event list and parameters +- Validator details + +Proposed system architecture for the upgrade can be illustrated as follows. + +

+ +
+ Figure 2 ChainViz v1 proposed system architecture +

+ +Upgraded system utilizes the **to-be-developed** SubVT `Block Details Service` to access the block content (i.e. extrinsics and events), and the **existing** SubVT `Validator Details Service` for any necessary validator data that is not available through the validator list service. + +##### Block Details Service + +A new addition to the [SubVT Backend](https://github.com/helikon-labs/subvt-backend), `Block Details Service` is going to be a websockets subscription service that pushes in JSON format at every new block to a subscribed client: + +- Block hash, parent block hash +- Block number +- Block author and its on-chain identity (if exists) +- Block contents + - Extrinsics, their module names and arguments + - Events, their module names and arguments + +This service is going to be utilized in both displaying the block contents and cross-chain messages as extracted from the `XcmPallet` extrinsics and events. + +#### UI/UX Upgrades + +We're going to implement a number of UI/UX upgrades, as explained below. + +- Improvement of the overall aesthetics and visual coherence of the application +- A better depiction of the block production process that's easier to comprehend for a wider range of users from the technically informed to the newly-introduced +- Display of block contents (i.e. hash, number, author, extrinsics and events) on hover and click +- Responsive design for a range of screen sizes +- A better utilization of the 3D space to allow for parachain visualization and preparation for future upgrades +- Display of parachains, their assigned validators and the cross-chain messaging process + +UI/UX upgrade implementation consists of 3 core components: + +- Visual guidelines +- Application UI/UX upgrades +- WebGL graphics development, shaders and motion design upgrades + +Development of the **visual guidelines** aims to bring visual coherency to ChainViz. From a functional perspective, this component serves as a core visual guide and foundation for all future UI/UX components and 3D graphics development. + +**UI/UX upgrades** aim to elevate the project from a draft look to an efficient, performant, user-appealing, scalable web application. Visually, it will be based on the current project aesthetics while ensuring its responsiveness and accessibility. Through this work, we aim to increase usability and ensure application scalability in terms of functionality growth. + +Third component of the visual upgrades, the development of the **upgraded WebGL graphics, shaders and motion**, faces a set of challenges that we aim to solve, including effective visualization of the block production and cross-chain messaging process. When we use the term effective visualization, we primarily mean one that: + +- Can show the depicted processes in a simple yet systematic manner +- Can be engaging and valuable for users with different levels of expertise + +### Ecosystem Fit + +There is currently no direct match in the Dotsama ecosystem of the features offered by ChainViz. ChainViz Alpha got [shared on Twitter](https://twitter.com/gavofyork/status/1491480880245874708) by Gavin Wood upon initial release, and received a lot of praise from various Dotsama ecosystem members. + +

+ +

+ +There are currently two other projects that visualize certain aspects of the Dotsama blockspace: + +1. [Kusamaverse by Odyssey](https://odyssey.org/kusamaverse), which is closer to a metaverse space for Kusama, focuses more on the interaction of the actors in the ecosystem. +2. [XCM Dashboard](https://polkadot.subscan.io/xcm_dashboard) by the Subscan team, which is a fairly static visualization of the active cross-chain messaging channels between parachains. + +ChainViz is unique in that it focuses on a very clear real-time visualization of the internals of the Dotsama machine. As we're going to explain in the Future Plans section, it also has the potential to have educational, entertainment and functional value through future development. + +## Team :busts_in_silhouette: + +### Team members + +- **Team Lead & Full-Stack Developer:** Kutsal Kaan Bilgin +- **Product Manager:** Egor Zmaznev +- **Project Manager:** Daria Kravchenko +- **Backend Developer:** Ivaylo Hubanov +- **UI/UX Designer:** [Ksenia Leonteva](https://www.behance.net/markeer) +- **3D Designer:** [Lena Sivakova](https://www.behance.net/hypnosphere) + +### Contact + +- **Contact Name:** Kutsal Kaan Bilgin +- **Contact Email:** kutsal@helikon.io +- **Contact Element/Matrix:** @helikon:matrix.org +- **Website:** [helikon.io](https://helikon.io) + +### Legal Structure + +- **Registered Address:** Omer Avni Mah. Balcik Sok. 4/4 34427 Beyoglu Istanbul Turkey +- **Registered Legal Entity:** Helikon Teknoloji ve Medya Tic. Ltd. Sti. + +### Team's experience + +#### Helikon Labs + +A crypto-native software development company based in Istanbul. Founded by [Kutsal Kaan Bilgin](https://github.com/kukabi), Helikon Labs got introduced into the Dotsama ecosystem in January 2021. Currently focused on validator tooling, infrastructure support and creative coding projects for the Dotsama ecosystem. + +- Received a Kusama treasury grant ([M1-3](https://kusama.polkassembly.io/treasury/99), [M4-5](https://kusama.polkassembly.io/treasury/129)) for: + - Completed + - [SubVT Backend](https://github.com/helikon-labs/subvt-backend) + - [SubVT Data Swift](https://github.com/helikon-labs/subvt-data-swift) + - [SubVT Data Android](https://github.com/helikon-labs/subvt-data-android) + - Alpha Testing + - [SubVT iOS](https://github.com/helikon-labs/subvt-ios) + - Under Development + - [SubVT Android](https://github.com/helikon-labs/subvt-ios) +- [Received](https://github.com/w3f/Grants-Program/blob/master/applications/subvt-telegram-bot.md) and [delivered](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/subvt_telegram_bot-milestones-1-and-2.md) a W3F Level-1 Open Grant for the [SubVT Telegram Bot](https://github.com/helikon-labs/subvt-backend/tree/development/subvt-telegram-bot) for [Kusama](https://t.me/subvt_kusama_bot) and [Polkadot](https://t.me/subvt_polkadot_bot). +- Member of both Polkadot and Kusama Thousand Validators programs. +- Running two Kusama validators, and one Polkadot validator on owned hardware in a colocation center in Istanbul. +- Active governance participation. + +#### Kutsal Kaan Bilgin + +Founder of Helikon Labs. Software developer with a BS in Computer Science and 20 years of experience in software development and leadership in diverse fields such as fintech, defense industry, interactive art installations and GIS. Focusing on user-friendly, aesthetically pleasing and creative blockchain application development since late 2019. Dotsama native since early 2021. Developer of SubVT (please see above), [ChainViz Alpha](https://alpha.chainviz.app) and [ChainSynth Alpha](https://alpha.chainsynth.app). Presenter of a Substrate Seminar [episode](https://www.youtube.com/watch?v=e-o_hTj3UFk&t=6119s&ab_channel=ParityTech) on blockchain UI application development. + +#### Egor Zmaznev + +Egor comes from a business analytics background with an emphasis on DeFi and web3 business models. He is proficient in R and Python in applications to ML modelling, focusing primarily on textual analytics in business applications with research emphasis on DeFi and DAOs. One of the co-founders of Klad Syndicate, where he managed a set of crypto projects varying from smart contract analytics to NFT marketplaces. + +#### Daria Kravchenko + +Daria focuses on internal team management. Coming from a conflictological education background, she can effectively set up and organise all of the internal communications and carry task management. Together with the designers, Daria worked on and finalized over 35 design projects only in the past year as a Klad Syndicate co-founder. Previously, managed design processes for the SubVT implementation. + +#### Ivaylo Hubanov + +Ivaylo Hubanov is coming from a strong Information Security engineering background with more than 15 years of experience in the field. He spent the last 5 years growing his passion for development and writing crypto and forex trading bots, and took part in a project for developing a 3D Fair in Unity. Also a member of Polkadot and Kusama Thousand Validators programs, he developed a complex validator orchestrator system for running validators on GCP instances while maintaining lower costs by using spot instances with low specs while inactive and high specs while active. The orchestrator required collecting live information from the chain and Ivaylo became the first developer to utilize and take part in the improvement of the SubVT websocket services. Worked together with Kutsal on improving the SubVT backend and the Telegram bots. + +#### Ksenia Leonteva + +Ksenia is a co-founder and leading UI/UX designer at Klad. She has 15 years of experience in web and UI/UX design and worked on over five crypto and DeFi-related projects over the past year. Ksenia has developed UI/UX design for the SubVT application: from the user-flow map and the wireframes to the whole app UI design. Focuses on clean user-friendly solutions, and ensures that the development team always have convenient files to work with. In 2022, won over ten web-design awards. + +#### Lena Sivakova + +Lena is a co-founder and 3D & motion designer at Klad. She has over seven years of experience and has participated in various crypto projects providing supporting 3D materials, including interactive validator 3D models for SubVT. Lena brings volume and movement to brands, allowing for spectacular immersive digital experiences. + +### Team Code Repos + +- [Helikon Labs](https://github.com/helikon-labs) + - [ChainViz](github.com/helikon-labs/chainviz) + - [ChainSynth](github.com/helikon-labs/chainsynth) + - [SubVT Backend](github.com/helikon-labs/subvt-backend) + - [SubVT iOS](github.com/helikon-labs/subvt-ios) + - [SubVT Android](github.com/helikon-labs/subvt-android) + - [SubVT Data - Swift](github.com/helikon-labs/subvt-data-swift) + - [SubVT Data - Android](github.com/helikon-labs/subvt-data-android) +- Team Members + - Kutsal Kaan Bilgin [@kukabi](https://github.com/kukabi) + - Egor Zmaznev [@Zmaznevegor](https://github.com/Zmaznevegor) + +### Team LinkedIn Profiles + +- [Egor Zmaznev](https://www.linkedin.com/in/zmaznevegor/) +- [Daria Kravchenko](https://www.linkedin.com/in/kravchenko-daria/) +- [Ivaylo Hubanov](https://www.linkedin.com/in/ihubanov) + +### Team Behance Profiles + +- [Ksenia Leonteva](https://www.behance.net/markeer) +- [Lena Sivakova](https://www.behance.net/hypnosphere) + + +## Development Status :open_book: + +[Alpha version](https://alpha.chainviz.app) of ChainViz has been live since February 2022 as detailed under the Project Details section. There hasn't been any development for the first major version proposed by this document. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 1.0 +- **Total Costs:** 22,000 USD + +### Milestone 1 — Block Details WS Service, Implementation of Upgrades for Existing Functionality + +- **Estimated duration:** 1 month +- **FTE:** 1.0 +- **Costs:** 11,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | GPLv3 | +| 0b. | Documentation | Milestone progress report and inline code documentation. GitHub README that explains how to run an instance of the application. | +| 0c. | Testing Guide | Separate markdown in the GitHub repository that documents the complete backend test cases for the Block Details WS Service and the application Typescript code and how to run them. | +| 0d. | Docker | Necessary Docker/compose files necessary to run the backend services and the application. | +| 0e. | Video Article | A YouTube video accompanied by an article on Helikon website or another blog site that documents the milestone development/design process and the outcome. | +| 0f. | Block Details WS Service Specification | Complete specification of the websockets service. | +| 1. | Block Details WS Service | Implementation of the service as part of [SubVT Backend](https://github.com/helikon-labs/subvt-backend), deployed and available on the SubVT test server. | +| 2. | Complete Upgrade of the Existing Functionality Available at [chainviz.app](https://chainviz.app) | Implementation of UI/UX upgrades for validator space and models, block production, network status panel, validator list panel and validator details panel. | + +### Milestone 2 - Rest of the Application Features: Block Details, Parachains, Paravalidators, XCM + +- **Estimated Duration:** 1 month +- **FTE:** 1.0 +- **Costs:** 11,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | GPLv3 | +| 0b. | Documentation | Milestone progress report and inline code documentation. GitHub README that explains how to run an instance. | +| 0c. | Testing Guide | Separate markdown in the GitHub repository that documents the complete application test cases and how to run them. | +| 0d. | Docker | Necessary Docker/compose files necessary to run the backend services and the application. | +| 0e. | Video Article | A YouTube video accompanied by an article on Helikon website or another blog site that documents the milestone development/design process and the outcome. | +| 1. | Complete Web Application with New Features | Web application live at [chainviz.app](https://chainviz.app), with additional real-time visualizations as documented above: complete block details on hover or click, parachains, parachain validator groups and their assignments, cross-chain messages. | + +## Future Plans + +- Add educational components and user guides. + - Replayable voice recordings attached to the various components and processes for the users who would like to learn more about the internals of the Dotsama machine. + - Text and visual augmentation. + - Animated explainers and hints that give better understanding of the technology and processes. +- Validator spaces and staking through ChainViz. Support for validators to claim and update their spaces. +- iOS and Android phone, table and watch applications. +- Exploration of VR and AR possibilities. +- Creating a wiki for validator operators, supporting pull requests. +- Adding indexes to provide insights for nominators (e.g. performance, telemetry data, reliability). +- Creating validator timeseries visualizations to provide insights on performance, reliability and stability. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +We have successfully [delivered](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/subvt_telegram_bot-milestones-1-and-2.md) a W3F Level-1 Open Grant. Please view the [application document](https://github.com/w3f/Grants-Program/blob/master/applications/subvt-telegram-bot.md) for the details of our first introduction to the Grants Program. + +**Awards Received** + +Some of the recent design awards that the design team have received: + +1. CSS Design awards ([link](https://www.cssdesignawards.com/sites/klad-syndicate/41871/)) +2. Awwwards ([link](https://www.awwwards.com/Klad/)) +3. Mindsparkle Mag ([link](https://mindsparklemag.com/website/klad-syndicate/)) \ No newline at end of file From 2de508879d9d05904306d98a178fecee8ffd5604 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Fri, 18 Nov 2022 08:20:46 +0100 Subject: [PATCH 032/959] Update accepted_grant_applications.md ChainViz v1 --- docs/accepted_grant_applications.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index eeb4da07673..cddde747f65 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -574,3 +574,4 @@ | [10Clouds Sp. z o.o.](https://10clouds.com/) | Crowdloan Front End Template | [GitHub](https://github.com/10clouds) | ☐ | ☐ | ☐ | | [DodoRare, Inc.](https://dodorare.com/) | Faterium | [GitHub](https://github.com/faterium) | ☐ | ☐ | ☐ | | [The Bacon Beacon](https://github.com/random-bacon) | Pallet Drand Client | [GitHub](https://github.com/random-bacon) | ☐ | ☐ | ☐ | +| [Helikon Labs](https://helikon.io/) | ChainViz v1 | [GitHub](https://github.com/helikon-labs/chainviz) | ☐ | ☐ | ☐ | From 85d32ddaae9a1512c26393d12f4893f63df3675a Mon Sep 17 00:00:00 2001 From: David Hawig Date: Fri, 18 Nov 2022 09:38:20 +0100 Subject: [PATCH 033/959] Update README.md Update status of crowdloan front-end_template --- rfps/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfps/README.md b/rfps/README.md index 98a8775a80e..18e2306c024 100644 --- a/rfps/README.md +++ b/rfps/README.md @@ -27,7 +27,7 @@ If you find an open RFP here that you think you can address, feel free to [submi | [anti-collusion_infrastructure.md](./open/anti-collusion_infrastructure.md) | :green_circle: | 29.11.2021 | | [appi.md](./implemented/appi.md) | :red_circle: | 20.07.2021 | | [candle-auction.md](./implemented/candle-auction.md) | :red_circle: | 02.02.2022 | -| [crowdloan_front_end_template.md](./open/crowdloan_front_end_template.md) | :green_circle: | 09.08.2022 | +| [crowdloan_front_end_template.md](./open/crowdloan_front_end_template.md) | :yellow_circle: | 18.11.2022 | | [epassport-zk-validation.md](./open/epassport-zk-validation.md) | :green_circle: | 29.11.2021 | | [formal_guarantees_for_grandpa.md](./open/formal_guarantees_for_grandpa.md) | :green_circle: | 07.10.2022 | | [identity-directory.md](./under_development/identity-directory.md) | :yellow_circle: | 30.05.2022 | From b749b5e1735e0f345682a41eb14b112634a4985c Mon Sep 17 00:00:00 2001 From: Noc2 Date: Fri, 18 Nov 2022 09:47:35 +0100 Subject: [PATCH 034/959] Update crowdloan front end rfp --- .../{open => under_development}/crowdloan_front_end_template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename rfps/{open => under_development}/crowdloan_front_end_template.md (96%) diff --git a/rfps/open/crowdloan_front_end_template.md b/rfps/under_development/crowdloan_front_end_template.md similarity index 96% rename from rfps/open/crowdloan_front_end_template.md rename to rfps/under_development/crowdloan_front_end_template.md index 69c3001597e..65a50153934 100644 --- a/rfps/open/crowdloan_front_end_template.md +++ b/rfps/under_development/crowdloan_front_end_template.md @@ -1,6 +1,6 @@ # Crowdloan Front End Template -* **Status:** Open +* **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/crowdloan_frontend_template.md) * **Proposer:** [SBalaguer](https://github.com/SBalaguer), [Noc2](https://github.com/Noc2) ## Project Description :page_facing_up: From f25c32de994bc145eb04f12b8980aca2cf70cfb4 Mon Sep 17 00:00:00 2001 From: Bryan Mutai Date: Fri, 18 Nov 2022 16:16:40 +0300 Subject: [PATCH 035/959] Crowdloans-FET Application (#1280) * Create Crowdloans-FET Application * Include Docker in milestone --- applications/Crowdloans-FET.md | 168 +++++++++++++++++++++++++++++++++ 1 file changed, 168 insertions(+) create mode 100644 applications/Crowdloans-FET.md diff --git a/applications/Crowdloans-FET.md b/applications/Crowdloans-FET.md new file mode 100644 index 00000000000..a679a3760b1 --- /dev/null +++ b/applications/Crowdloans-FET.md @@ -0,0 +1,168 @@ +# The CrowdloanFET Project + +- **Team Name:** Mutai Solutions +- **Payment Address:** 0xE27F2E8321Fb4c32525a4ED86d2902dbA63491E4 Ethereum (USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + + **This application is response to the [Crowdloan Front End Template RFP](https://github.com/w3f/Grants-Program/blob/master/rfps/open/crowdloan_front_end_template.md)** + +The CrowdloanFET project is a free and opensource white-label solution for Polkadot projects to showcase the Crowdloan to prospective and current project supporters and community members. + +Built using Nextjs, Tailwind and Polkadotjs, projects can easily configure/modify and deploy a frontend for their crowdloan campaign, either on their own infrastructure that supports node or on affordable/free platforms like Vercel. + +The template will come with an unopinionated style and will provide the appropriate information architecture for different projects to add on top of and apply their own brand assets. + + +## Project Details + +### Technology stack overview: + + - Framework: **Next.js**, built using Typescript + - Styling and branding config: **Tailwind** + - Wallet/on-chain data & network interactions: **Polkadotjs** + +### Configuration: + +To make the template generic & simple to configure, we shall use 3 main points of modifation: + +- **Markdown Files** - To populate the project copy thorough various sections of the template +- **.ENV configuration file** - To configure various settings that may be required for querying data on-chain and various other uses around the template. A few config variables to include would be: `PARA_ID`, `HOMEPAGE_LINK`, `DISCORD_INVITE_LINK`, `TWITTER_ACCOUNT_USERNAME`, `BLOG_LINK`, etc +- **Tailwind.config.js** - To configure key branding aspects. e.g Colours, Font, etc + +These as well as further configuration steps shall be outlined the accompanying documentation and tutorial article. + + +### Mockups: + +### Project Overview/Description Section + +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202225912-19b5906d-e532-40ce-bfb4-376d44bf381c.png) + + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202226004-2c7ac951-db82-4704-8c58-e744d9aa28e1.png) + + +### Crowdloan details & timeline Section +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202226870-2e319a79-5d36-441b-90df-6c670f4fc995.png) + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202226931-d3da8dfc-b45e-42fe-ad80-99c21e460a67.png) + +### Crowdloan Rewards Section: + +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202229039-c810bde8-8860-43da-a165-02c89d5e6e6c.png) + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202229444-51223716-aa35-440d-9db2-8a177f927eb1.png) + + +### Crowdloan Contributions Section: + +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202388654-9b8bb827-a74d-4885-b767-d282f8f4e575.png) + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202388697-b7971a33-1adb-4d42-9115-f81802c251ec.png) + +### Competing crowdloans Section: + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202399108-f1c388fd-06df-4c46-9e1d-030c7719f4b2.png) + + +### FAQ Section: + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202399482-2cf6ba84-bff1-4845-bbfd-7aaca1919203.png) + + +### Ecosystem Fit + +As outlined above in the Project Overview, this project is targeted toward project maintainers and their respective communities/contributors that are undertaking a crowdloan campaign. This ideally would help with eliviating some of the workload on the project maintainers while also providing conclusive visibility of a crowdloan to the wider Polkadot ecosystem at large and an easy approach to contributing to it. + +Similar implementations/projects: + + - https://acala.network/acala/join-acala + - https://mantanetwork.medium.com/the-calamari-crowdloan-on-kusama-74a3cb2a2a4b + +## Team :busts_in_silhouette: + +### Team members + +- **Bryan Mutai** : Full-Stack developer and web designer + +### Contact + +- **Contact Name:** Bryan Mutai +- **Contact Email:** work@bryanmutai.co + +### Legal Structure + +- **Registered Address:** 90 JGO, James Gichuru Road, Lavington, Nairobi, Kenya - P.O.Box 1669-00100 Nairobi GPO +- **Registered Legal Entity:** Mutai Solutions + +### Team's experience + +I studied software engineering at the University of Glasgow, I currently have 5 years experience in web design & development and have been working as a freelance web developer, working in various programming languages (Typescript/Python) and in various frameworks and libraries (React/Angularjs/Django). Over the past 2 years I have also been contributing towards various blockchain related opensource projects. Recently in particular: + +- Designed & built a Voting Delegation Dashboard for the APWine DAO using React/Typescript/Tailwind - https://vote-delegation-dashboard.vercel.app/ +- Contributions to the Shapeshift Web App & related KeepKey hardware wallet features. - https://github.com/shapeshift/web/commits?author=brymut +- Integrating price data for Superfluid tokens into the Gnosis Safe web app backend - https://github.com/safe-global/safe-eth-py/pull/381 +- Added support for Zora NFTs viewing & the Celo blockchain onto the Mask.io browser plugin - https://github.com/DimensionDev/Maskbook/commit/810999f38a09df8d5cefb490b4ca475b837458bc & https://github.com/DimensionDev/Maskbook/commit/c5cfdf393baf6cf7997f66cbabc5e5952dc8cb4d +- Github Page: [https://github.com/](https://github.com/brymut/) + +### Team LinkedIn Profiles + +- [https://www.linkedin.com/in/bryanmutai/](https://www.linkedin.com/in/bryanmutai/) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration**: 1 Month +- **Full-Time Equivalent (FTE)**: 1 +- **Total Costs**: 5,600 USD + +### Milestone 1 + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 5,600 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can deploy an instance of the template for their project| +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 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 that explains the core functionality of the template and intended use as well as a step by step tutorial targeted towards developers on how to configure, modify & deploy the template on a popular hosting platform like Vercel | +| 1. | Template User interface implementation | I will design and implement the template UI using Tailwind in the Nextjs framework. The user interface will include: Project information, rewards schema, current contributions, time left in the crowdloan and information on the contribtions made after the crowdloan ends as shown simulated in the mockups above | +| 2. | Contribution form & interaction | A simple interface for users to contribute directly through the deployed template through the entire cycle contribution, handling both a finalised contribution as well as any encountered errors | +| 3. | Example User interface | Using the output from 1 & 2 I will create a sample crowdloan deployment that would be the result of implementing the Front End template following the steps outlined in the output from 0d. | + + +## Future Plans + +- Core maintainance of project, such as critical bugs and security updates +- Implementing/merging community suggestions/Pull Requests on features that could help improve the experience of both deploying and using the template. +- Collecting feedback from projects that consider/use this template. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website From df6d7649cbe6c602bb71a30b92bbefedd9158964 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Fri, 18 Nov 2022 20:01:44 +0100 Subject: [PATCH 036/959] Update accepted_grant_applications.md Crowdloans-FET --- docs/accepted_grant_applications.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index cddde747f65..c35bbb84890 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -575,3 +575,4 @@ | [DodoRare, Inc.](https://dodorare.com/) | Faterium | [GitHub](https://github.com/faterium) | ☐ | ☐ | ☐ | | [The Bacon Beacon](https://github.com/random-bacon) | Pallet Drand Client | [GitHub](https://github.com/random-bacon) | ☐ | ☐ | ☐ | | [Helikon Labs](https://helikon.io/) | ChainViz v1 | [GitHub](https://github.com/helikon-labs/chainviz) | ☐ | ☐ | ☐ | +| [Mutai Solutions](https://bryanmutai.co/) | Crowdloans-FET | [GitHub](https://github.com/brymut) | ☐ | ☐ | ☐ | From d523d56b7bd53b101a9af1aa04e504f04b50c7f1 Mon Sep 17 00:00:00 2001 From: Aleixo Sanchez <15819210+alxs@users.noreply.github.com> Date: Fri, 18 Nov 2022 20:04:23 +0100 Subject: [PATCH 037/959] Terminate Quantum Lock for QBITCOIN (#1283) https://github.com/w3f/Grants-Program/pull/904#issuecomment-1297382772 --- applications/quantumLock.md | 1 + 1 file changed, 1 insertion(+) diff --git a/applications/quantumLock.md b/applications/quantumLock.md index 20cf332eb98..ce0a72abc44 100644 --- a/applications/quantumLock.md +++ b/applications/quantumLock.md @@ -5,6 +5,7 @@ - **Team Name:** BQP - **Payment Address:** 0x063c75324504D1595a972462A30A230d703f655e (ETH) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/904#issuecomment-1297382772) ## Project Overview :page_facing_up: From ceebb52da56e306b8592316ef8da2052e0e0ef62 Mon Sep 17 00:00:00 2001 From: Aleixo Sanchez <15819210+alxs@users.noreply.github.com> Date: Sat, 19 Nov 2022 11:01:10 +0100 Subject: [PATCH 038/959] Terminate Setheum HighEnd LaunchPad Crowdsales Module (#1284) --- applications/setheum-launchpad-crowdsales-pallet.md | 1 + 1 file changed, 1 insertion(+) diff --git a/applications/setheum-launchpad-crowdsales-pallet.md b/applications/setheum-launchpad-crowdsales-pallet.md index 53461006acf..fe1846b28e6 100644 --- a/applications/setheum-launchpad-crowdsales-pallet.md +++ b/applications/setheum-launchpad-crowdsales-pallet.md @@ -8,6 +8,7 @@ - **Team Name:** Setheum Labs - **Payment Address:** 3NaU6UHe9MQyb5d2mFS49DJqaWMsuw7NKd (BTC) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/823#issuecomment-1297355678) > ⚠️ *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.* From be63ac1a6d28239ef85f3f0628d25eeb1f9192a6 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Mon, 21 Nov 2022 10:11:28 +0100 Subject: [PATCH 039/959] Update crowdloan_front_end_template.md Add second team --- rfps/under_development/crowdloan_front_end_template.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfps/under_development/crowdloan_front_end_template.md b/rfps/under_development/crowdloan_front_end_template.md index 65a50153934..428a955fba7 100644 --- a/rfps/under_development/crowdloan_front_end_template.md +++ b/rfps/under_development/crowdloan_front_end_template.md @@ -1,6 +1,6 @@ # Crowdloan Front End Template -* **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/crowdloan_frontend_template.md) +* **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/crowdloan_frontend_template.md), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/Crowdloans-FET.md) * **Proposer:** [SBalaguer](https://github.com/SBalaguer), [Noc2](https://github.com/Noc2) ## Project Description :page_facing_up: From 4696c8eeb2f231c6703eac01471a786c81287e0c Mon Sep 17 00:00:00 2001 From: Aleixo Sanchez <15819210+alxs@users.noreply.github.com> Date: Mon, 21 Nov 2022 14:58:58 +0100 Subject: [PATCH 040/959] Update accepted_grant_applications.md --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index c35bbb84890..d558d93c59e 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -204,7 +204,7 @@ | [Halva](https://github.com/halva-suite) | A toolchain for improving the experience of developing Decentralized Applications based on Substrate | [GitHub](https://github.com/halva-suite) | ☐ | ☒ | ☒ | | [Subscan](subscan.io) | Substrate explorer | [GitHub](https://github.com/itering/subscan) | ☐ | ☒ | ☒ | | [t3rn](https://github.com/t3rn/t3rn) | A protocol for blockchain interoperability | [GitHub](https://github.com/t3rn/t3rn) | ☐ | ☒ | ☒ | -| [Stake Technologies](https://stake.co.jp/) | Hardware ECDSA for Polkadot JS | [GitHub](https://github.com/polkadot-js) | ☐ | ☐ | ☐ | +| [Stake Technologies](https://stake.co.jp/) | Hardware ECDSA for Polkadot JS | [GitHub](https://github.com/polkadot-js) | ☐ | ☒ | ☒ | | [Protofire](https://protofire.io/) | Failover mechanism for validators upgrade | [GitHub](https://github.com/protofire) | ☐ | ☒ | ☐ | | [DappForce](http://dappforce.io) | SubSocial Chapter 2 | [GitHub](https://github.com/dappforce/dappforce-subsocial) | ☐ | ☒ | ☒ | | [OpenSquare Network](https://www.opensquare.network/) | A blockchain based crowdsourcing and reputation platform | [GitHub](https://github.com/opensquare-network) | ☐ | ☒ | ☒ | From 823f5369aa536e85a354ccc687598b6c75706f3c Mon Sep 17 00:00:00 2001 From: ashWhiteHat Date: Mon, 21 Nov 2022 23:41:29 +0900 Subject: [PATCH 041/959] update timeline and company entity (#1288) --- applications/zero-network.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/applications/zero-network.md b/applications/zero-network.md index f6d481aeb03..1644af1d536 100644 --- a/applications/zero-network.md +++ b/applications/zero-network.md @@ -4,7 +4,7 @@ - **Project Name:** Zero Network - **Team Name:** Zero Network -- **Payment Address:** 0x6fA7BAB5fB3A644af160302de3Badc0958601b44 (DAI) +- **Payment Address:** 0x9061b0787D28d0fDaD845d670F7505EAE5F3B01B (DAI) - **Level:** 2 ## Project Overview :page_facing_up: @@ -109,14 +109,14 @@ Considering both sides, the zero knowledge scheme is related deeply to calculati ### Contact -* **Contact Name:** Artree LLC -* **Contact Email:** info@artree.co.jp -* **Website:** [Artree](https://artree.co.jp/) +* **Contact Name:** Invers Inc +* **Contact Email:** info@invers.tech +* **Website:** [Invers](https://invers.tech/) ### Legal Structure -- **Registered Address:** 2F Hamamatutyo Dia Building, 2-2-15 Hamamatsucho, Minato-ku, Tokyo-to 105-0013, Japan -- **Registered Legal Entity:** Artree LLC. +- **Registered Address:** 2F・3F Emblem Nishiarai, 3-33-6 Umejima, Adachi City, Tokyo-to 121-0816, Japan +- **Registered Legal Entity:** Invers Inc. ### Team's experience @@ -221,7 +221,7 @@ In `Milestone 3`, we are going to implement `wallet` which provides the user to | Milestone | Deliverable | Estimated Duration (month) | Deadline | | -----: | ----------- | ------------- | ------------- | -| 1 | Confidential Transfers | 2 | 2022 1/7 | +| 1 | Confidential Transfers | 2 | 2023 1/7 | | 2 | Confidential Smart Contract Executions | 3 | 2023 4/7 | | 3 | Confidential Smart Contract Executions | 1.5 | 2023 5/26 | From fb2af6065f3f9ce25b4f39a0eb52d38d37cd4fbe Mon Sep 17 00:00:00 2001 From: Stefan Date: Mon, 21 Nov 2022 21:45:05 +0700 Subject: [PATCH 042/959] Amend Gafi Milestone 3 (#1279) --- applications/Gafi.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/applications/Gafi.md b/applications/Gafi.md index 46ae84afe36..984dd2eb01e 100644 --- a/applications/Gafi.md +++ b/applications/Gafi.md @@ -176,7 +176,7 @@ Whitepaper: Coming soon - **Total Estimated Duration:** 11.5 months - **Full-Time Equivalent (FTE):** 1.2 FTEs -- **Total Costs:** 59,000 USDT +- **Total Costs:** 52,700 USDT ### Milestone 1 — The Heroes & Empires @@ -245,11 +245,10 @@ In this milestone, the requirements will fall into acceptance criteria: - **Estimated duration:** 4 months - **FTE:** 1.2 -- **Costs:** 19,000 USD +- **Costs:** 12,700 USD In this milestone, the requirements will fall into acceptance criteria: + Gafi Network Testnet launch with at least 5 nodes -+ Build DAO to vote on-chain governance + Pallet Game-Creator works + Determine the 'x' number of limit discount transactions per minute by Testnet and vote by on-chain governance + Determine the 'y' percentage to reduce transaction fee by Testnet and vote by on-chain governance @@ -267,9 +266,8 @@ In this milestone, the requirements will fall into acceptance criteria: | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | 0e. | Article | wiki.gafi.network and Medium | | 1. | Substrate module: pallet game-creator | https://wiki.gafi.network/learn/game-creator | -| 2. | Substrate module: pallet_dao | module to vote on-chain runtime data | -| 3. | Weights/Benchmarking | implement benchmarking for pallets to determine appropriate weights | -| 4. | Demo | Demo new features in milestone 3 with guide article | +| 2. | Weights/Benchmarking | implement benchmarking for pallets to determine appropriate weights | +| 3. | Demo | Demo new features in milestone 3 with guide article | ## Future Plans From e037fe117a5622ac010124510283313e7848ea57 Mon Sep 17 00:00:00 2001 From: Keegan | W3F <35080151+keeganquigley@users.noreply.github.com> Date: Tue, 22 Nov 2022 12:18:35 -0500 Subject: [PATCH 043/959] Update accepted_grant_applications.md (#1297) --- docs/accepted_grant_applications.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/accepted_grant_applications.md b/docs/accepted_grant_applications.md index d558d93c59e..86b5ef0cc9e 100644 --- a/docs/accepted_grant_applications.md +++ b/docs/accepted_grant_applications.md @@ -526,7 +526,7 @@ | [Karolis Ramanauskas](https://krl.is/) | Generic Sybil-Resistant Faucet | [GitHub](https://github.com/karooolis) | ☐ | ☒ | ☒ | | [LimeChain](https://limechain.tech/) | Research feasibility for a Go Runtime | [GitHub](https://github.com/LimeChain) | ☐ | ☒ | ☒ | | [Jim Yam](https://github.com/JimYam) | daos | [GitHub](https://github.com/daos-org/daos.git) | ☐ | ☒ | ☐ | -| [Green Lemon](https://github.com/GreenLemonProtocol) | Green Lemon Protocol | [GitHub](https://github.com/GreenLemonProtocol) | ☐ | ☒ | ☐ | +| [Green Lemon](https://github.com/GreenLemonProtocol) | Green Lemon Protocol | [GitHub](https://github.com/GreenLemonProtocol) | ☐ | ☒ | ☒ | | [Stardust Labs Inc.](https://stardust.finance/) | Integrating ISO-8583 | [GitHub](https://github.com/adit313/) | ☐ | ☒ | ☒ | | [TwinP](https://www.linkedin.com/in/elioprifti/) | Escrow Pallet | [GitHub](https://github.com/herou) | ☐ | ☒ | ☒ | | [Meta Defender Team](https://github.com/Meta-Defender/) | Meta Defender | [GitHub](https://github.com/Meta-Defender/) | ☐ | ☐ | ☐ | From 57ef638f2bb331c24c569bff02f04c2b3e89bfb0 Mon Sep 17 00:00:00 2001 From: David Hawig Date: Wed, 23 Nov 2022 00:23:49 +0100 Subject: [PATCH 044/959] Website (#1296) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * test page deployment (#1292) * Rename .github/publish.yml to .github/workflows/publish.yml * Test commit * Update publish.yml * Update publish.yml * Update docusaurus.config.js * Fix image links * Rename applications category * Move Apply in header to right * Restructure Process docs * Fix header link * Update index.md (#1295) * Update team.md Update team md * Fix emojis * Update .github/workflows/publish.yml * Re-fix links * Add latest changes from master * add docusaurus folders to gitignore * Fix hyperlink for docusaurus * Remove emoji from page title * add accepted grants doc * remove accepted grants doc * restore accepted doc * Update accepted_grant_applications.md (#1297) (#1298) Co-authored-by: Keegan | W3F <35080151+keeganquigley@users.noreply.github.com> Co-authored-by: Sebastian Müller Co-authored-by: Keegan | W3F <35080151+keeganquigley@users.noreply.github.com> --- .github/workflows/publish.yml | 26 + .gitignore | 5 + README.md | 32 +- applications/AdMeta.md | 32 +- applications/Afloat.md | 144 +++-- applications/AlgoCash.md | 61 +- applications/Apron_Network.md | 97 ++- applications/BCANN.md | 62 +- applications/Banksy_Finance.md | 4 +- applications/CESS.md | 136 ++-- ...Cere_Turnkey_Private_Blockchain_Network.md | 3 +- applications/Coinversation.md | 3 +- applications/DICO.md | 37 +- applications/DKSAP.md | 3 +- applications/DNFT.md | 3 +- applications/Dante_Network.md | 3 +- applications/Datagen_Project.md | 52 +- applications/DipoleOracle.md | 3 +- applications/DistributedKeyManagement.md | 142 ++--- applications/DotPay.md | 139 ++--- applications/DotPulse.md | 68 +- applications/Doter.md | 138 +++-- applications/EverlastingCash.md | 188 +++--- applications/FIAT-on-off-ramp.md | 3 +- applications/Faucet.md | 3 +- applications/Fennel_Protocol.md | 181 +++--- applications/Gafi.md | 4 +- ...ralized_hardware_crypto_wallet_services.md | 183 +++--- applications/GreenLemon.md | 3 +- applications/Idavoll Network.md | 28 +- applications/Integrating-ISO8583.md | 22 +- applications/Interstellar-Network.md | 138 ++--- applications/InvArch.md | 227 +++---- applications/JuniDB.md | 120 ++-- .../KSM-embeddable-tip-or-donate-button.md | 3 +- applications/Koiverse.md | 122 +--- applications/Libra.md | 86 +-- applications/MAP-Bridge.md | 4 +- applications/MIXER.md | 3 +- applications/MIXERv2.md | 3 +- applications/Maki.md | 3 +- applications/MangoBOX-Protocol.md | 5 +- applications/Meta_Defender.md | 206 +++--- applications/NFTStore_Network.md | 3 +- ...col_for_NFT_Migration_and_Data_Exchange.md | 3 +- applications/Nolik.md | 136 ++-- applications/NuLink.md | 4 +- applications/OpenSquare-offchain-voting.md | 87 +-- applications/OpenSquare_paid_qa_protocol.md | 105 ++-- applications/ParaSpell.md | 122 ++-- applications/Parallel.md | 151 ++--- applications/Plus-follow-up.md | 3 +- applications/Plus-social-recovery-wallet.md | 3 +- applications/Plus.md | 3 +- applications/PolkaKey.md | 3 +- applications/PolkaSignIn.md | 73 ++- applications/Polkadart.md | 3 +- applications/Polkadot-Dart.md | 49 +- applications/Polkadot_Web_UI.md | 4 +- applications/Polkaholic.md | 3 +- applications/Polkawatch.md | 3 +- applications/Primis.md | 29 +- applications/QRUCIAL_DAO.md | 36 +- ...ining data, De-Fi and NFTs on Substrate.md | 3 +- ....md => RainbowDAO Protocol ink Phase 1.md} | 5 +- applications/RareLink.md | 3 +- applications/RedStone Network.md | 62 +- applications/Relation-Graph.md | 54 +- applications/Roloi.md | 3 +- applications/RubeusKeeper.md | 3 +- applications/RubyProtocol.md | 155 ++--- .../SEOR-code-less-smart-contract-platform.md | 3 +- applications/SaaS3.md | 202 +++--- applications/Shivarthu.md | 117 ++-- applications/Societal.md | 44 +- applications/SpiderDAO.md | 117 ++-- applications/Standard_Protocol.md | 387 ++++++------ applications/Starry_Network.md | 3 +- applications/SubDAO-Chrome-Extension.md | 72 +-- applications/SubDAO_Network.md | 3 +- applications/SubDAO_PolkaSign.md | 70 +-- applications/SubGame_Network.md | 15 +- applications/SubGame_Network_m2.md | 3 +- applications/SubIdentity.md | 3 +- applications/SubsCrypt.md | 3 +- applications/Subsembly-GRANDPA.md | 64 +- applications/TREX_Network.md | 3 +- applications/UMC-Tokenscribe.md | 3 +- applications/Web3Go.md | 121 ++-- applications/Whiteflag-on-Fennel.md | 83 +-- applications/XPredictMarket.md | 60 +- applications/ZeroDAO_Network.md | 37 +- applications/ZeroPool.md | 77 ++- applications/Zondax-Support.md | 3 +- applications/_category_.yml | 2 + applications/ajuna_network_follow_up.md | 141 +++-- .../anagolay-project-idiyanale-phase-1.md | 99 ++- applications/application-template.md | 32 +- applications/ares_protocol.md | 3 +- applications/assemblyscript-scale-codec.md | 48 +- applications/asylum.md | 3 +- applications/asylum_follow_up_1.md | 63 +- applications/bdwallet.md | 73 ++- applications/bit_country.md | 3 +- applications/bit_country_m2.md | 3 +- applications/blackprint-js.md | 5 +- applications/bldg_app.md | 74 ++- applications/bounce-protocol.md | 44 +- applications/bright_treasury.md | 3 +- applications/c++polkadot-light-client.md | 3 +- applications/cScale.md | 19 +- applications/candle_auction_ink.md | 3 +- applications/canyon_network.md | 15 +- applications/ces_data_store.md | 3 +- applications/chainjs.md | 3 +- applications/chainviz.md | 18 +- applications/cheersland.md | 104 ++-- applications/choko_wallet.md | 95 ++- applications/citadel.md | 30 +- applications/clover_network.md | 53 +- applications/crossbow.md | 58 +- applications/crowdloan_frontend_template.md | 16 +- ...olab-staking-reward-collector-front-end.md | 26 +- applications/curve_amm.md | 4 +- applications/daos.md | 40 +- applications/dart-scale-codec.md | 38 +- .../decentralized_well-being_game_api.md | 22 +- applications/deeper_network.md | 47 +- applications/deip.md | 3 +- applications/delmonicos.md | 46 +- applications/dora-factory-molochdao-v1-v2.md | 55 +- applications/dorahacks-quadratic-funding.md | 39 +- applications/dot_marketplace-phase2.md | 45 +- applications/dot_marketplace.md | 183 +++--- applications/dotmog.md | 150 +++-- applications/epirus_substrate_explorer.md | 157 +++-- applications/epirus_substrate_phase_2.md | 77 ++- applications/escrow_pallet.md | 3 +- applications/evanesco_networks.md | 3 +- applications/example-project.md | 3 +- applications/faceless.md | 152 ++--- applications/fair_squares.md | 146 ++--- applications/faterium.md | 40 +- applications/fractapp.md | 79 ++- applications/halva_bootstrapping.md | 9 +- applications/halva_framework.md | 15 +- applications/hamster.md | 3 +- applications/helixstreet.md | 5 +- applications/hex.md | 3 +- applications/hs-web3.md | 56 +- applications/imbue_network.md | 51 +- applications/index.md | 584 ++++++++++++++++++ applications/ink-explorer.md | 3 +- applications/ipfs_utilities.md | 24 +- applications/iris.md | 3 +- applications/iris_followup.md | 3 +- applications/java-client.md | 3 +- applications/keysafe_network.md | 23 +- applications/klevoya_fuzzer.md | 49 +- applications/konomi.md | 99 +-- applications/kylin_network.md | 3 +- applications/liberland.md | 359 +++++------ applications/lip_payments.md | 45 +- applications/logion_wallet.md | 4 +- applications/lunie.md | 48 +- applications/manta_network.md | 181 +++--- applications/massbit_route.md | 89 ++- applications/mobile-game-framework.md | 3 +- applications/mobile_dapp_connection.md | 8 +- .../multisignature_management_tool.md | 3 +- applications/mybank.md | 3 +- applications/native-bitcoin-vaults.md | 5 +- applications/new-order.md | 55 +- applications/new_bls12_hash_function.md | 3 +- applications/newomega-m3m4.md | 3 +- applications/newomega.md | 3 +- applications/nft_collectibles_wallet.md | 92 ++- applications/nft_explorer.md | 187 +++--- applications/nft_product_analytics_suite.md | 26 +- applications/on-chain-cash.md | 3 +- applications/open-node-framework.md | 89 ++- applications/openbrush-follow-up-2.md | 126 ++-- applications/openbrush-follow-up.md | 72 +-- applications/openbrush.md | 93 ++- applications/openrollup-mvp-phase-1.md | 3 +- applications/pacific_store.md | 3 +- applications/pallet_maci.md | 3 +- applications/pallet_supersig.md | 164 +++-- applications/panic.md | 3 +- applications/parachain-staking.md | 3 +- applications/parami-protocol.md | 3 +- applications/perun_app_channels.md | 3 +- applications/perun_channels-integration.md | 113 ++-- applications/perun_channels.md | 76 +-- applications/pesa_pallet.md | 9 +- applications/php-rpc-lib.md | 4 +- applications/php-scale-lib.md | 3 +- applications/php-substrate-api.md | 55 +- applications/plip.md | 62 +- applications/polk-auction.md | 71 +-- applications/polkadex.md | 3 +- applications/polkadot-desktop-app.md | 15 +- .../polkadot-js-extension-per-account-auth.md | 3 +- applications/polkadotjs-ecdsa.md | 3 +- applications/polkadotjs-hardware.md | 23 +- applications/polkadotjs_no_code.md | 3 +- applications/polkaj_android_support.md | 41 +- applications/polkakeeper.md | 3 +- applications/polkamusic.md | 234 +++---- applications/polkashots.md | 3 +- applications/polkastarter.md | 28 +- applications/polkastats.md | 3 +- applications/polket_toearnfun.md | 39 +- applications/pontem.md | 3 +- applications/project_1001.md | 44 +- applications/project_aurras_mvp_phase_1.md | 82 ++- applications/project_aurras_mvp_phase_2.md | 3 +- applications/project_bodhi.md | 118 ++-- applications/prosopo.md | 219 +++---- applications/quadratic-funding.md | 97 +-- applications/quantumLock.md | 4 +- applications/rb_substrate_client.md | 41 +- .../research-feasibility-go-runtime.md | 3 +- .../saito-game-protocol-and-engine.md | 3 +- applications/scale-codec-comparator.md | 21 +- applications/sensio_network.md | 3 +- applications/sequester.md | 5 +- .../setheum-launchpad-crowdsales-pallet.md | 24 +- applications/setheum.md | 70 ++- applications/shadows-network.md | 68 +- applications/signac.md | 103 +-- applications/skyekiwi-protocol.md | 81 +-- applications/skyepass.md | 135 ++-- applications/skynet-substrate-integration.md | 45 +- applications/slonigiraf.md | 167 ++--- applications/social_recovery_wallet.md | 80 ++- applications/sol2ink.md | 3 +- applications/spacewalk-bridge.md | 3 +- applications/spartan_poc_consensus_module.md | 109 ++-- applications/sr25519_donna.md | 24 +- applications/stable-asset.md | 22 +- .../staking-rewards-collector-front-end.md | 20 +- applications/stardust.md | 37 +- applications/starks_network.md | 102 +-- applications/stone-index-on-substrate.md | 3 +- applications/subalfred.md | 29 +- applications/subauction.md | 45 +- applications/subdex.md | 3 +- applications/subquery.md | 68 +- applications/subrelay.md | 61 +- applications/subscript_lang.md | 23 +- applications/substats.md | 3 +- applications/substrate-identity-directory.md | 109 ++-- applications/substrate-tutorials.md | 3 +- applications/substrate_client_java.md | 3 +- applications/substrate_core_polywrapper.md | 118 ++-- applications/substrate_startkit_GUI.md | 3 +- applications/subvt-telegram-bot.md | 15 +- applications/subwallet.md | 3 +- applications/sukhavati_poc_module.md | 3 +- applications/sunrise-dex.md | 3 +- applications/sunshine-keybase.md | 3 +- applications/sup.md | 3 +- applications/tdot.md | 46 +- applications/tribal_protocol.md | 43 +- applications/typechain-polkadot-follow-up.md | 32 +- applications/typechain-polkadot.md | 3 +- applications/uke-protocol.md | 58 +- applications/uke.md | 54 +- applications/universaldot-me.md | 5 +- applications/universaldot.me.md | 4 +- applications/upgradeability-by-proxy.md | 3 +- applications/uplink.md | 25 +- applications/vanguard.md | 3 +- applications/ventur.md | 212 +++---- applications/vera_defi.md | 4 +- applications/verida_network.md | 37 +- applications/visualize_rust_lifetime.md | 3 +- applications/wasm-opt-for-rust.md | 4 +- applications/wasm_runtimes_fuzzing.md | 32 +- applications/wasmedge_substrate.md | 3 +- applications/web3-compatible-api.md | 3 +- applications/wika_network.md | 375 +++++------ applications/workflow_testing.md | 3 +- applications/xbi-format-psp-t3rn.md | 45 +- applications/xcm-sdk.md | 3 +- applications/xtokens.md | 71 ++- applications/yatima.md | 86 +-- applications/yiban_chen1.md | 19 +- applications/yieldscan_phase_2.md | 186 +++--- applications/zenlink-cross-chain-dex.md | 3 +- applications/zenlink-smart-contract.md | 3 +- applications/zenlink.md | 3 +- applications/zero-network.md | 24 +- applications/zk-plonk.md | 38 +- applications/zk-rollups.md | 53 +- babel.config.js | 3 + docs/Applications | 1 + docs/Introduction/_category_.yml | 2 + docs/Introduction/ideas.md | 13 + docs/Introduction/index.md | 10 + docs/Introduction/intro.md | 31 + docs/Introduction/levels.md | 29 + docs/Introduction/support.md | 9 + docs/Introduction/team.md | 49 ++ docs/Process/_category_.yml | 2 + docs/Process/changes.md | 10 + docs/Process/how-to-apply.md | 23 + docs/Process/index.md | 30 + docs/Process/milestone_delivery.md | 8 + docs/Process/review.md | 11 + docs/{ => Support Docs}/T&Cs.md | 0 .../announcement-guidelines.md | 0 .../grant-badge-guidelines.md | 4 +- .../grant_guidelines_per_category.md | 0 .../milestone-deliverables-guidelines.md | 0 docs/{ => Support Docs}/polkadot_stack.md | 4 +- docs/accepted_grant_applications.md | 32 +- docs/contribute.md | 13 + docs/faq.md | 47 +- docs/funding.md | 35 ++ docs/help.md | 39 ++ docs/maintenance.md | 25 + docs/referral-program.md | 8 + .../rfps/Implemented}/appi.md | 0 .../rfps/Implemented}/candle-auction.md | 0 .../rfps/Implemented}/ksm-tipping-button.md | 0 .../on-chain-quadratic-funding.md | 0 .../rfps/Implemented}/php-api.md | 0 .../rfps/Implemented}/php-scale.md | 0 .../staking-rewards-collector-front-end.md | 0 {rfps/open => docs/rfps/Open}/ISO_20022.md | 0 .../rfps/Open}/a-and-v-topology.md | 0 ...ternative_polkadot_host_implementations.md | 0 .../Open}/anti-collusion_infrastructure.md | 0 .../rfps/Open}/epassport-zk-validation.md | 0 .../Open}/formal_guarantees_for_grandpa.md | 0 .../rfps/Open}/implementation-benchmarking.md | 0 .../rfps/Open}/move_smart_contract_pallet.md | 0 .../rfps/Open}/polkadot-collator-setup.md | 0 .../rfps/Open}/raft-validators.md | 0 .../open => docs/rfps/Open}/sub-consensus.md | 0 .../rfps/Open}/validator-setup-maintenance.md | 0 {rfps/open => docs/rfps/Open}/xcm-tool.md | 0 docs/rfps/README.md | 61 ++ .../rfps/Under Development}/ISO_8583.md | 0 .../crowdloan_front_end_template.md | 0 .../Under Development}/identity-directory.md | 0 .../ink_smart_contract_block_explorer.md | 0 .../multi-chain-block-explorer.md | 0 .../privacy-enhancement-polkadot-extension.md | 0 .../scale-codec-comparator.md | 0 .../social-recovery-wallet.md | 0 .../uncollateralized-stablecoin-research.md | 0 {rfps => docs/rfps}/suggestion-template.md | 0 docs/suggesting_a_project.md | 24 + docusaurus.config.js | 148 +++++ package.json | 44 ++ rfps/README.md | 57 -- sidebars.js | 30 + src/components/HomepageFeatures.js | 59 ++ src/components/HomepageFeatures.module.css | 14 + src/css/custom.css | 42 ++ src/pages/index.js | 40 ++ src/pages/index.module.css | 25 + static/.nojekyll | 0 {src => static/img}/Grants_Program.png | Bin .../Polkadot_Logo_Horizontal_BlackOnWhite.svg | 1 + static/img/Web3Foundation.png | Bin 0 -> 15328 bytes {src => static/img}/badge_black.svg | 0 static/img/everyone-1.svg | 271 ++++++++ static/img/icon-documentation.svg | 1 + {src => static/img}/like.png | Bin {src => static/img}/map.png | Bin {src => static/img}/medium.png | Bin {src => static/img}/reddit.png | Bin {src => static/img}/rfp-header.png | Bin {src => static/img}/twitter.png | Bin {src => static/img}/web.png | Bin .../img}/web3 foundation grants_black.jpg | Bin {src => static/img}/youtube-play.png | Bin 381 files changed, 8914 insertions(+), 7188 deletions(-) create mode 100644 .github/workflows/publish.yml rename applications/{RainbowDAO Protocol ink! Phase 1.md => RainbowDAO Protocol ink Phase 1.md} (99%) create mode 100644 applications/_category_.yml create mode 100644 applications/index.md create mode 100644 babel.config.js create mode 120000 docs/Applications create mode 100644 docs/Introduction/_category_.yml create mode 100644 docs/Introduction/ideas.md create mode 100644 docs/Introduction/index.md create mode 100644 docs/Introduction/intro.md create mode 100644 docs/Introduction/levels.md create mode 100644 docs/Introduction/support.md create mode 100644 docs/Introduction/team.md create mode 100644 docs/Process/_category_.yml create mode 100644 docs/Process/changes.md create mode 100644 docs/Process/how-to-apply.md create mode 100644 docs/Process/index.md create mode 100644 docs/Process/milestone_delivery.md create mode 100644 docs/Process/review.md rename docs/{ => Support Docs}/T&Cs.md (100%) rename docs/{ => Support Docs}/announcement-guidelines.md (100%) rename docs/{ => Support Docs}/grant-badge-guidelines.md (96%) rename docs/{ => Support Docs}/grant_guidelines_per_category.md (100%) rename docs/{ => Support Docs}/milestone-deliverables-guidelines.md (100%) rename docs/{ => Support Docs}/polkadot_stack.md (59%) create mode 100644 docs/contribute.md create mode 100644 docs/funding.md create mode 100644 docs/help.md create mode 100644 docs/maintenance.md create mode 100644 docs/referral-program.md rename {rfps/implemented => docs/rfps/Implemented}/appi.md (100%) rename {rfps/implemented => docs/rfps/Implemented}/candle-auction.md (100%) rename {rfps/implemented => docs/rfps/Implemented}/ksm-tipping-button.md (100%) rename {rfps/implemented => docs/rfps/Implemented}/on-chain-quadratic-funding.md (100%) rename {rfps/implemented => docs/rfps/Implemented}/php-api.md (100%) rename {rfps/implemented => docs/rfps/Implemented}/php-scale.md (100%) rename {rfps/implemented => docs/rfps/Implemented}/staking-rewards-collector-front-end.md (100%) rename {rfps/open => docs/rfps/Open}/ISO_20022.md (100%) rename {rfps/open => docs/rfps/Open}/a-and-v-topology.md (100%) rename {rfps/open => docs/rfps/Open}/alternative_polkadot_host_implementations.md (100%) rename {rfps/open => docs/rfps/Open}/anti-collusion_infrastructure.md (100%) rename {rfps/open => docs/rfps/Open}/epassport-zk-validation.md (100%) rename {rfps/open => docs/rfps/Open}/formal_guarantees_for_grandpa.md (100%) rename {rfps/open => docs/rfps/Open}/implementation-benchmarking.md (100%) rename {rfps/open => docs/rfps/Open}/move_smart_contract_pallet.md (100%) rename {rfps/open => docs/rfps/Open}/polkadot-collator-setup.md (100%) rename {rfps/open => docs/rfps/Open}/raft-validators.md (100%) rename {rfps/open => docs/rfps/Open}/sub-consensus.md (100%) rename {rfps/open => docs/rfps/Open}/validator-setup-maintenance.md (100%) rename {rfps/open => docs/rfps/Open}/xcm-tool.md (100%) create mode 100644 docs/rfps/README.md rename {rfps/under_development => docs/rfps/Under Development}/ISO_8583.md (100%) rename {rfps/under_development => docs/rfps/Under Development}/crowdloan_front_end_template.md (100%) rename {rfps/under_development => docs/rfps/Under Development}/identity-directory.md (100%) rename rfps/under_development/ink!_smart_contract_block_explorer.md => docs/rfps/Under Development/ink_smart_contract_block_explorer.md (100%) rename {rfps/under_development => docs/rfps/Under Development}/multi-chain-block-explorer.md (100%) rename {rfps/under_development => docs/rfps/Under Development}/privacy-enhancement-polkadot-extension.md (100%) rename {rfps/under_development => docs/rfps/Under Development}/scale-codec-comparator.md (100%) rename {rfps/under_development => docs/rfps/Under Development}/social-recovery-wallet.md (100%) rename {rfps/under_development => docs/rfps/Under Development}/uncollateralized-stablecoin-research.md (100%) rename {rfps => docs/rfps}/suggestion-template.md (100%) create mode 100644 docs/suggesting_a_project.md create mode 100644 docusaurus.config.js create mode 100644 package.json delete mode 100644 rfps/README.md create mode 100644 sidebars.js create mode 100644 src/components/HomepageFeatures.js create mode 100644 src/components/HomepageFeatures.module.css create mode 100644 src/css/custom.css create mode 100644 src/pages/index.js create mode 100644 src/pages/index.module.css create mode 100644 static/.nojekyll rename {src => static/img}/Grants_Program.png (100%) create mode 100755 static/img/Polkadot_Logo_Horizontal_BlackOnWhite.svg create mode 100644 static/img/Web3Foundation.png rename {src => static/img}/badge_black.svg (100%) create mode 100644 static/img/everyone-1.svg create mode 100644 static/img/icon-documentation.svg rename {src => static/img}/like.png (100%) rename {src => static/img}/map.png (100%) rename {src => static/img}/medium.png (100%) rename {src => static/img}/reddit.png (100%) rename {src => static/img}/rfp-header.png (100%) rename {src => static/img}/twitter.png (100%) rename {src => static/img}/web.png (100%) rename {src => static/img}/web3 foundation grants_black.jpg (100%) rename {src => static/img}/youtube-play.png (100%) diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml new file mode 100644 index 00000000000..5f98f93ed7c --- /dev/null +++ b/.github/workflows/publish.yml @@ -0,0 +1,26 @@ +name: Publish website + +on: + push: + branches: + - master + +jobs: + build: + name: build and deploy + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@master + - uses: actions/setup-node@v2 + with: + node-version: "16.16.0" + - uses: actions/checkout@v2 + with: + fetch-depth: 0 + + - name: Publish + run: | + git config --global user.email "grants-deployer@users.noreply.github.com" + git config --global user.name "grants-deployer" + echo "machine github.com login grants-deployer password ${{ secrets.ACCESS_KEY }}" > ~/.netrc + yarn && yarn build && GIT_USER=grants-deployer PUBLISHING=true yarn deploy diff --git a/.gitignore b/.gitignore index c706597d5c7..e7642e57fd0 100644 --- a/.gitignore +++ b/.gitignore @@ -61,3 +61,8 @@ $RECYCLE.BIN/ # IDE settings .vscode +node_modules + +# docusaurus +build/ +.docusaurus/ \ No newline at end of file diff --git a/README.md b/README.md index c65c962e0a8..680070a648a 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ # Web3 Foundation Grants Program

- +

@@ -10,20 +10,22 @@ - [Project ideas](#project-ideas) - [Support](#support) - [Team](#team) -- [:level_slider: Levels](#level_slider-levels) +- [:level\_slider: Levels](#level_slider-levels) - [:pencil: Process](#pencil-process) - [1. Application](#1-application) - [2. Application Review](#2-application-review) - [3. Milestone Delivery and Payment](#3-milestone-delivery-and-payment) - [Changes to a Grant after Approval](#changes-to-a-grant-after-approval) -- [:mailbox_with_mail: Suggest a Project](#mailbox_with_mail-suggest-a-project) -- [:hammer_and_wrench: Maintenance Grants](#hammer_and_wrench-maintenance-grants) -- [:moneybag: Referral Program](#moneybag-referral-program) +- [:mailbox\_with\_mail: Suggest a Project](#mailbox_with_mail-suggest-a-project) +- [:hammer\_and\_wrench: Maintenance Grants](#hammer_and_wrench-maintenance-grants) +- [:moneybag: Referral Program](#moneybag-referral-program) - [:bulb: Help](#bulb-help) - [Additional information](#additional-information) - [Real-time conversation](#real-time-conversation) - [Office Hours](#office-hours) - [:rocket: Alternative Funding Sources](#rocket-alternative-funding-sources) + - [Substrate Builders Program vs Treasury vs Web3 Grants](#substrate-builders-program-vs-treasury-vs-web3-grants) + - [Substrate Builders Program](#substrate-builders-program) - [Treasury](#treasury) - [Hackathons](#hackathons) - [Other Grant Programs](#other-grant-programs) @@ -103,7 +105,7 @@ In cases where a niche expert opinion is desirable, one of the committee members Evaluators are individuals able to evaluate the technology delivered as a result of the Grants Program. The committee has the right to add or remove evaluators on the basis of supermajority. - [Nabil Abdellaoui](https://github.com/randombishop) -- [Matteo Casonato](https://github.com/0xCaso) +- [Matteo Casonato](https://github.com/0xCaso) - [David Hawig](https://github.com/Noc2) - [Diogo Mendonça](https://github.com/dsm-w3f) - [Sebastian Müller](https://github.com/semuelle) @@ -222,13 +224,13 @@ Please note that: We give away 500 USD to each referral of a successful grant application by _anyone having previously worked on a Web3 Foundation grant_ or _a [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors)_. Web3 Foundation and Parity employees do not qualify for the program, even if they previously worked on a grant. -In order to be eligible for the referral bonus, the application itself must contain the name of the [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors) or the GitHub account of the grantee as well as the payment address for the referral bonus (see the [application template](applications/application-template.md)). Payment is made in Bitcoin, USDT (on Kusama or Ethereum), USDC/DAI (Ethereum) or aUSD (Acala). +In order to be eligible for the referral bonus, the application itself must contain the name of the [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors) or the GitHub account of the grantee as well as the payment address for the referral bonus (see the [application template](applications/application-template.md)). Payment is made in Bitcoin, USDT (on Kusama or Ethereum), USDC/DAI (Ethereum) or aUSD (Acala). ## :bulb: Help ### Additional information -| | | | | | | +| | | | | | | | :-: | :-: | :-: | :-: | :-: | :-: | | [W3F Website](https://web3.foundation) | [W3F Twitter](https://twitter.com/web3foundation) | [W3F Medium](https://medium.com/web3foundation) | [Polkadot Wiki](https://wiki.polkadot.network/en/) | [Web 3.0 Reddit](https://www.reddit.com/r/web3) | [W3F YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) | @@ -247,11 +249,13 @@ Besides, we also have a **community room for all grant recipients**. Head over t ### Office Hours Web3 Foundation Grants Office Hours are a chance to ask the grants team questions regarding a specific (potential) grant application. It offers -- general guidance regarding the grants program, + +- general guidance regarding the grants program, - some quick initial feedback and -- help how to navigate the ecosystem. +- help how to navigate the ecosystem. + +Apply for Office Hours if you -Apply for Office Hours if you - need feedback before submitting an application, - want to find out what kind of support there might be available or - need help finding the resources you need. @@ -288,9 +292,9 @@ flowchart LR click H "https://www.substrate.io/builders-program/" "https://www.substrate.io/builders-program/" _blank ``` -### Substrate Builders Program +### Substrate Builders Program -The [Substrate Builders Program](https://substrate.io/ecosystem/substrate-builders-program/) directly supports you by connecting you with Parity’s extensive resources. +The [Substrate Builders Program](https://substrate.io/ecosystem/substrate-builders-program/) directly supports you by connecting you with Parity’s extensive resources. ### Treasury @@ -316,7 +320,7 @@ Below is a list of other grant programs in the Polkadot/Substrate ecosystem: - [Darwinia Grants Program](https://github.com/darwinia-network/collaboration/blob/master/grant/README.md#grant-program) - [Edgeware Grants and Bounties](https://gov.edgewa.re/discussion/1132-edgeware-proposal-process-and-template) - [HydraDX Grants and Bounties](https://docs.hydradx.io/new_deal/) -- [Interlay Labs Grants Program](https://github.com/interlay/Grants-Program) +- [Interlay Labs Grants Program](https://github.com/interlay/Grants-Program) - [Moonbeam Grants Program](https://moonbeam.foundation/grants/) - [OAK’s Developer Grants](https://oak.tech/community/grants/) - [Picasso / Composable Grants Program](https://grants.composable.finance) diff --git a/applications/AdMeta.md b/applications/AdMeta.md index e4e74b0039a..a31ffbea789 100644 --- a/applications/AdMeta.md +++ b/applications/AdMeta.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# AdMeta -- **Project Name:** AdMeta - **Team Name:** AdMeta - **Payment Address:** 0x1D346c4F0732674a1fc69b4bAFBa854F53353C35 (ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 @@ -73,7 +72,7 @@ Dr. John Wu - Core Dev of Litentry Parachain Team. The University of Tokyo - **Contact Name:** Han Zhao - **Contact Email:** windzhaohan@gmail.com -- **Website:** https://admeta.network/ +- **Website:** ### Legal Structure @@ -94,28 +93,28 @@ Note: Both [Litentry](https://www.litentry.com/) and [Web3Go](https://github.com ### Team Code Repos -- https://github.com/litentry/litentry-parachain -- https://github.com/litentry/litentry-pallets -- https://github.com/web3go-xyz/web3go +- +- +- Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. -- https://github.com/h4n0 Han Zhao -- https://github.com/Shihao66 Shihao Zhao -- https://github.com/Moehringen Hao Ding +- Han Zhao +- Shihao Zhao +- Hao Ding ### Team LinkedIn Profiles (if available) -- https://www.linkedin.com/in/zhaohan6 -- https://www.linkedin.com/in/shihao-zhao-55752685/ -- https://www.linkedin.com/in/hao-ding-msc-pmp-64411193/ +- +- +- ## Development Status :open_book: -- https://github.com/AdMetaNetwork/admeta This is the AdMeta Substrate chain implementation. We already started to build the pallets mentioned in Milestone 1 below. -- https://github.com/AdMetaNetwork/admeta-webapp This is our web app repo according to Milestone 1. We already had a single page app with polkadot js API integrated now. -- https://github.com/AdMetaNetwork/admeta-decentraland This is a simple asset built with Decentraland SDK, and currently it's just for a demo purpose. -- https://admeta.network/ We also have the first version of our website. +- This is the AdMeta Substrate chain implementation. We already started to build the pallets mentioned in Milestone 1 below. +- This is our web app repo according to Milestone 1. We already had a single page app with polkadot js API integrated now. +- This is a simple asset built with Decentraland SDK, and currently it's just for a demo purpose. +- We also have the first version of our website. ## Development Roadmap :nut_and_bolt: @@ -127,7 +126,6 @@ Please also provide the GitHub accounts of all team members. If they contain no ### Milestone 1 — Substrate Chain with Impression Ad, Web App - - **Estimated duration:** 6 month - **FTE:** 2 - **Costs:** 12,000 USD diff --git a/applications/Afloat.md b/applications/Afloat.md index ef5ebaa149f..9b7ba518047 100644 --- a/applications/Afloat.md +++ b/applications/Afloat.md @@ -1,22 +1,20 @@ -# W3F Grant Proposal +# Afloat Tax Infrastructure Polkadot Integration -- **Project Name:** Afloat Tax Infrastructure Polkadot Integration - **Team Name:** Afloat Inc. - **Payment Address:** bc1q0aghk8qufzwpmrp5nfyu9r7dh3yynmphk7rhjj - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 - ## Overview [Afloat](https://stayafloat.io/#/) is one of the first real-use cases of blockchain technology in the accounting industry. It enables the fractional buying and selling of tax credits that historically have been inefficient, opaque, and centralized. It has already processed tax credits ranging in orders from $2K -$70k USD. -Afloat was built on a private Ethereum clone but wants to migrate to Polkadot due to its technology, identity management, and community. Parachains like Kilt and their identity services would be crucial at validating government roles and professional certifications like accountants and institutional sellers. +Afloat was built on a private Ethereum clone but wants to migrate to Polkadot due to its technology, identity management, and community. Parachains like Kilt and their identity services would be crucial at validating government roles and professional certifications like accountants and institutional sellers. ## Project Details ### Background -A common tax credit is for land preservation. The inhabitants of a geographic area recognize that their shared quality of life may be positively impacted if more land was preserved rather than developed. If the owner of land property in that area agrees to preserve land, they may be eligible to receive a tax credit in an amount associated with the value of the land property. However, some owners of tax credits do not have enough tax liability to take full advantage of the reward. Because of this, a number of states allow credits to be transferred. State transferable tax credits are typically bought and sold at a discount. +A common tax credit is for land preservation. The inhabitants of a geographic area recognize that their shared quality of life may be positively impacted if more land was preserved rather than developed. If the owner of land property in that area agrees to preserve land, they may be eligible to receive a tax credit in an amount associated with the value of the land property. However, some owners of tax credits do not have enough tax liability to take full advantage of the reward. Because of this, a number of states allow credits to be transferred. State transferable tax credits are typically bought and sold at a discount. Historically, the tax credit industry’s transfer process has been deeply inefficient. Due to a lack of trust between buyers and sellers, accountants and lawyers act as middlemen. This added financial and procedural cost creates an entry barrier for the majority of taxpayers into the tax credit market. What remains is a tight-knit group of wealthy buyers, sellers, and policymakers. @@ -29,29 +27,19 @@ With the ability to tap into a market sector that knows nothing about blockchain Having started in the US, Afloat, Inc., a Wyoming company, is compliant with existing federal, state, and local regulations and takes care of the entire transfer process with the following functions: - Uploading proof of tax credit ownership -

- -

-
+![Image](https://user-images.githubusercontent.com/7217054/159963378-b850c316-aa28-46ea-9a87-2e184de57a0d.png) - Linking a US bank account -

- -

-
+![Image](https://user-images.githubusercontent.com/7217054/159963375-a06565dc-9f19-4aa9-8e31-a6223aa2cef8.png") - Fiat integration using Dwolla, a third party company - Placing buy and sell limit orders on blockchain -

- -

-
+ +![Image](https://user-images.githubusercontent.com/7217054/159963749-d7e2ef89-fac0-4f4c-a823-9dd3a4e9d263.png) - Algorithmic matching overlapping full or partial orders in a ”pending” status while waiting for government approval -

- -

-
+ +![Image](https://user-images.githubusercontent.com/7217054/159963752-dc5f9323-1d07-4bc5-b309-ab2147ff71b8.png) - Autopopulate tax forms with blockchain data (Afloat supports five of thirty-six US tax forms) - Completion of government paperwork and money transfer after government approval @@ -73,9 +61,9 @@ To handle fractional tax credits in Substrate we are using "fruniques". That is An earlier implementation of this used a fungible token to represent the parts of the tax credit, but we've found that fractional NFTs fit the mental model a bit better and more ergonomically in existing tools. A user is buying a "thing", see that thing in their wallet, where they may hold 7 of them. Holding various quantities of 7 different fungible tokens seemed to increase the complexity more than necessary. This is a design element we frequently brainstorm on though. In a future release, it may be useful to have fruniques support both use cases. -This proposal covers the migration or creation of the following: +This proposal covers the migration or creation of the following: -1. User onboarding (set and verify identity with gatekeeper parameters) and slides. +1. User onboarding (set and verify identity with gatekeeper parameters) and slides. 2. Sign and Login with email. 3. Originate and configure a tax credit and create sales orders for tax credits. 4. Support for encrypted files attached to tax credits. @@ -86,11 +74,7 @@ This proposal covers the migration or creation of the following: ### Workflow -

- -

-
- +![Image](https://user-images.githubusercontent.com/7217054/160020369-b64ae31d-8cc5-49ce-8c4d-82dea85546cf.png) ## Ecosystem Fit @@ -103,6 +87,7 @@ The secondary target audience are the community of developers that will benefit As the perfect technology for record-keeping, blockchain makes a lot of sense for accountants. Afloat not only wants to bring its infrastructure to Polkadot but also bring Polkadot into the accounting community with the following: #### Continuing Education for CPAs + Afloat’s founder and current CEO [Louise Reed](https://www.linkedin.com/in/louisewreed/) has given talks at a number of CPE conferences, where CPAs receive continuing education credits to maintain their licenses each year. Introducing her to Web 3 infrastructure would allow her to speak about it at CPA conferences, especially to other CPAs looking for classes covering new and interesting topics and ideas. #### Crypto Clients @@ -114,9 +99,11 @@ Working in a historically conservative industry, CPAs are starting to feel the p Typically, sellers of tax credits are large international businesses, which are usually slow with internal changes. However, familiarity with the tax credit market paves the way for an easier introduction to a new technology. #### Buyers + Introducing programming/blockchain/crypto taxpayers to tax savings by way tax credits would bring new customers to a marketplace that has a strong history of centralization, opacity, and insularity. #### Bridging Communities + Afloat would naturally bridge two opposing communities: accounting, the most trusted and conservative industries, and blockchain, one of the most innovative industries. By association with such a trusted industry, blockchain would receive credibility in the eyes of the general public while also modernizing accounting with new and better processes. #### Natural Use Case @@ -134,7 +121,6 @@ Louise Reed is scheduled to speak at the following Certified Public Accountant S | 9/26/2022 | VA (+ VA Tech) | Roanoke | | 11/17/2022 | VA (+ VA Tech) | Virginia Beach | - ## Team :busts_in_silhouette: ### Team members @@ -145,12 +131,11 @@ Louise Reed is scheduled to speak at the following Certified Public Accountant S - Erick Casanova - Blockchain Engineer - Abel Yanez - Substrate Developer - ### Contact - **Contact Name:** Louise Reed - **Contact Email:** louise@stayafloat.io -- **Website:** https://stayafloat.io/#/ +- **Website:** ### Legal Structure @@ -163,33 +148,35 @@ With a master's degree in physics from Duke University and a Master of Accountin Afloat is partnering with Hashed Systems DAO LLC, a substrate development team with years of experience building blockchain applications. They have worked on substrate and Polkadot since spring 2021. Their developers completed Brian Chen's course and have experience running substrate chains and have significant experience working with the Uniques, Identity and Node-authorization pallets. Additional relevant experience below: - [Hypha DAO](https://dho.hypha.earth/#/): Smart contracts and front end development that enables the creation of flexible roles, assignments and contributions with recurring payments. Design and implement a graph data layer to improve web application performance. Design and build a [Double Entry accounting](https://us02web.zoom.us/rec/share/eRqiBvq-dsV0L_hEjW5e8DWNYQlUn2bLhI8-86jkRVwdXiN3TiD5edym17ubCd9R.QhKQw_Byy0t5_8SW?startTime=1647371674000) (Passcode: .V$C#Br2) plattform that streams wallet activity, supports token price history, reporting and currency conversion. [SEED](https://joinseeds.earth/): Smart contract and mobile development that capture the project's constitution, enable voting on proposals and basic identity management like reputation, vote history etc. Design and build a PWA token swaps app. Design and build a basic [Economic Simulator](https://seeds-sim.hypha.earth/dashboard) that enables voters to understand the economic impact of policy changes. - ### Relevant profile links -- Louise Reed CPA website: https://louisereedcpa.com/ -- Louise Reed LinkedIn: https://www.linkedin.com/in/louisewreed/ -- Abel on Github: https://github.com/amatsonkali -- Jose Maria on Github: https://github.com/jmgayosso and Gitlab: https://gitlab.com/jmgayosso -- Hashed website: https://hashed.io/ -- Erick on GitHub: https://github.com/tlacloc +- Louise Reed CPA website: +- Louise Reed LinkedIn: +- Abel on Github: +- Jose Maria on Github: and Gitlab: +- Hashed website: +- Erick on GitHub: ## Development Roadmap :nut_and_bolt: + ### Overview + - **Total Estimated Duration:** 13 weeks - **Full-Time Equivalent (FTE):** 2 FTE (across 5 contributors) - **Total Costs:** 46,200 USD #### Languages -- All pallets will be developed in Rust. + +- All pallets will be developed in Rust. - The custodial/persistence partner backend will be developed in Nodejs, with a slight possibility of porting it to Rust. - The front end will be Angular, with a possibility that it will be migrated to Vuejs. -### Milestone 1 — User onboarding (set and verify identity with gatekeeper parameters) and slides. +### Milestone 1 — User onboarding (set and verify identity with gatekeeper parameters) and slides + - **Estimated duration:** 5 weeks - **FTE:** 2 - **Costs:** 17,675 USD @@ -204,10 +191,10 @@ Afloat is partnering with Hashed Systems DAO LLC, a substrate development team w | 0e. | Article | We will publish an **article** in English and Spanish that explains what was built and how it can benefit other projects | | 1. | Set Profile and Upload KYC Materials | User onboarding web client for uploading identity details in a privacy preserving manner. Data will be encrypted and only accessible by 1) the user, 2) a pre-specified KYC administrator account, and 3) a persistence partner/custodian that the user or app administrator selects. | | 2. | KYC Admin | KYC administrator screen for viewing and approving new user (market participant) requests. We plan to use the existing `registrar` process on the Identity pallet. UI is in Angular, with a small chance we may migrate it to Vuejs | -| 3. | Slides |1-3 additional presentation slides for Louise W. Reed, CPA’s currently scheduled talks at CPA conferences regarding blockchain, cryptocurrency, triple-entry accounting and transferring state tax credits. The additional slides will be added to address why Afloat sees value in being supported by Polkadot’s ecosystem| +| 3. | Slides |1-3 additional presentation slides for Louise W. Reed, CPA’s currently scheduled talks at CPA conferences regarding blockchain, cryptocurrency, triple-entry accounting and transferring state tax credits. The additional slides will be added to address why Afloat sees value in being supported by Polkadot’s ecosystem| +### Milestone 2 — Originate and configure a tax credit and create sales order for tax credits -### Milestone 2 — Originate and configure a tax credit and create sales order for tax credits. - **Estimated duration:** 4 weeks - **FTE:** 2 - **Costs:** 14,140 USD @@ -221,12 +208,12 @@ Afloat is partnering with Hashed Systems DAO LLC, a substrate development team w | 0d. | Video | We will provide a video demonstration that will illustrate all of the functionality delivered with this milestone. | | 0e. | Article | We will publish an **article** in English and Spanish that explains what was built and how it can benefit other projects | 1. | Originate Tax Credit | Web client for onboarding new tax credits as NFTs, appropriate metadata persisted using the Uniques and likely Statemint specifications. | -| 2. | Upload Confidential Documents | This feature allows for NFT originators to upload encrypted files attached to tax credits. The files will be accessible only by the user and the application administartor. | +| 2. | Upload Confidential Documents | This feature allows for NFT originators to upload encrypted files attached to tax credits. The files will be accessible only by the user and the application administartor. | | 3. | Tax Credit verification | MVP Tax Credit pallet, compatible with the prebuilt Uniques pallet (and/or RMRK), will support data validation rules by jurisdiction and tax credit type. The user will be able to save a draft of their tax credit if they need to identify more IRL steps to fix discrepancies. It's like a 'tax credit compiler'. | -| 4. | List for Sale | Ability for Tax Credit (NFT) owners to assign a price and list it for sale.| +| 4. | List for Sale | Ability for Tax Credit (NFT) owners to assign a price and list it for sale.| +### Milestone 3 — Sell the entire or a fraction of the tax credit to interested buyers using fruniques pallets -### Milestone 3 — Sell the entire or a fraction of the tax credit to interested buyers using fruniques pallets. - **Estimated duration:** 2 weeks - **FTE:** 2 - **Costs:** 7,070 USD @@ -239,11 +226,12 @@ Afloat is partnering with Hashed Systems DAO LLC, a substrate development team w | 0c. | Testing | Unit testing will be applied to ensure reliability. Documentation of tests and results will be provided | | 0d. | Video | We will provide a video demonstration that will illustrate all of the functionality delivered with this milestone. | | 0e. | Article | We will publish an **article** in English and Spanish that explains what was built and how it can benefit other projects -| 1. | Order Part of an NFT | Web client and pallet support for fractionalizing a Tax Credit NFT. Users may specify the % and/or direct amount for the order. Rust and Angular/Vuejs | -| 2. | Complete/Confirm Order | Sell the entire or a fraction of the tax credit to interested buyers using fruniques pallets. Rust and Angular/Vuejs | +| 1. | Order Part of an NFT | Web client and pallet support for fractionalizing a Tax Credit NFT. Users may specify the % and/or direct amount for the order. Rust and Angular/Vuejs | +| 2. | Complete/Confirm Order | Sell the entire or a fraction of the tax credit to interested buyers using fruniques pallets. Rust and Angular/Vuejs | | 3. | Order Settlement | Ensure the marketplace correctly calculates appropriate commissions and fees. Calculations will be in Rust, displayed in application using Angular/Vuejs | -### Milestone 4 — Redeem the tax credit and confirm redemption and freeze/burn asset on-chain. +### Milestone 4 — Redeem the tax credit and confirm redemption and freeze/burn asset on-chain + - **Estimated duration:** 2 weeks - **FTE:** 2 - **Costs:** 7,070 USD @@ -258,59 +246,67 @@ Afloat is partnering with Hashed Systems DAO LLC, a substrate development team w | 0e. | Article | We will publish an **article** in English and Spanish that explains what was built and how it can benefit other projects | 1. | Approve Redemption Specialists | Pallet and web client for onboarding and approving/enrolling Tax Credit Redemption Specialists. These are experts that know how to perform appropriate steps to migrate a tax credit IRL. Approval will be handled by marketplace administrator initially, by the community eventually. | | 2. | Request Redemption | Pallet and web function/form for requesting redemption, optionally from a specific Redemption Specialist or system will choose. | -| 3. | View materials and Redeem | Pallet support and web client for Redemption Specialist to review the encrypted tax credit materials and confirm that off-chain IRL redemption has been completed. Redemption completion will be approved by owner and Redemption specialist. | +| 3. | View materials and Redeem | Pallet support and web client for Redemption Specialist to review the encrypted tax credit materials and confirm that off-chain IRL redemption has been completed. Redemption completion will be approved by owner and Redemption specialist. | | 4. | Asset Manager | Once part or all of a tax credit NFT is redeemed, the Tax Credit Asset Manager(s) will be able to lock, freeze, and/or burn the NFT. | | 5. | Launch Materials | Launch materials, videos and speaking arrangements for Louise are already in queue.| - + ## Future Plans + ### Immediate Use -All Afloat users will be migrated to the substrate application and benefit from the identity and security enhancements. Afloat will gain access to the full substrate ecosystem and vice versa. + +All Afloat users will be migrated to the substrate application and benefit from the identity and security enhancements. Afloat will gain access to the full substrate ecosystem and vice versa. ### Next Phases + This proposal covers Afloat migration of the current functionality. Below are future phases that expand it: #### Phase 2 -User scenarios: -- Registration/approval of new appraisers, -- Request appraisal of NFT, -- Appraise NFT, + +User scenarios: + +- Registration/approval of new appraisers, +- Request appraisal of NFT, +- Appraise NFT, - Review and compensate appraiser -Web client for: +Web client for: + - NFT creator to request judgment and grant access to Asset Grader(s) - Asset Grader to review materials and provide judgment #### Phase 3 -User scenarios: -- More advanced ordering and pricing models, -- Candle auctions, + +User scenarios: + +- More advanced ordering and pricing models, +- Candle auctions, - Improved compatibility with more jurisdictions. #### Phase 4 + - Provide API access and referral program for tax industry participants. (e.g. allow existing systems and networks to seamlessly integrate) ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** Raul Romanutti recommended the program on a call with Louise Reed, Max Gravitt and Augusto Lara on March 21st, 2022. ### Additional Context + #### State Tax Credit Breakdown + Currently, forty-one states offer tax credits designed to incentivize economically and socially desirable behavior, like historic structure rehabilitation, land preservation and film production. + - Linking a US bank account -

- -

-
+ +![Image](https://user-images.githubusercontent.com/7217054/160020375-0e360e26-17f9-4856-8266-1e95b76efc7c.png) + Thirty-four of those states allow the producers of these credits to be incentivized even if they do not have enough state income to fully utilize the credits and/or need the cash flow to further expand the incentivized behavior. -

- -

-
+ +![Image](https://user-images.githubusercontent.com/7217054/160020372-8190f4aa-81aa-4b0e-ae1b-d92eb031df5b.png) Blockchain Friendly State Breakdown -

- -

-
-https://www.investopedia.com/news/majority-us-states-are-still-acknowledge-cryptocurrencies/ \ No newline at end of file + +![Image](https://user-images.githubusercontent.com/7217054/160020643-84313880-4e0b-4942-8b1a-7278eb7aa219.png) + + diff --git a/applications/AlgoCash.md b/applications/AlgoCash.md index f2db43a9dc4..ddd6083f483 100644 --- a/applications/AlgoCash.md +++ b/applications/AlgoCash.md @@ -1,13 +1,11 @@ -# Open Grant Proposal +# AlgoCash > This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/blob/master/README_2.md) on how to submit a proposal. - - -* **Project Name:** Algo Cash * **Team Name:** Reserve Labs * **Payment Address:** DAI Address: 0x3f91475fbd0c3d9c676d39af071691c1cf635f0b -## Project Overview + +## Project Overview ### Overview @@ -25,15 +23,13 @@ Algo Cash is implemented as a smart contract which can be deployed into ink! pal For trading and liquidity purpose, Algo Cash could be integrated with such protocols in Polkadot as Konomi and Zenlink. - -## Project Details +## Project Details ### Tokens #### ALC - Algo Cash -Algo Cash tokens are designed to be used as a medium of exchange. The built-in stability mechanism expands and contracts their supply, maintaining their peg to the aUSD token. - +Algo Cash tokens are designed to be used as a medium of exchange. The built-in stability mechanism expands and contracts their supply, maintaining their peg to the aUSD token. #### ALB - Algo Bonds @@ -67,7 +63,6 @@ Every 24 hours, the time-weighted average of the ALC-aUSD exchange rate is read The stabilization mechanism is triggered whenever the price of Algo Cash is observed to be above / below (1+ε) aUSD, where ε is a parameter that defines the range of price stability for the ALC token. In inilization, ε is set to be 0.05. - #### Contractionary Policy At any point in time, Algo Bonds can be bought from the protocol in exchange for Algo Cash. Purchase of Bonds are performed at an algorithmically set price. With a Algo Cash oracle price of P aUSD, bonds are sold off at a price of P ALC (effective price being P^2 aUSD), promising bond holders a premium when redeemed. Purchased bonds can be converted to Algo Cash, insofar as the preconditions are met and the Treasury is not empty. @@ -104,26 +99,22 @@ Advantages **cash - Minting and burning of the cash token** -Mints *amount* cash to the *recipient* account. +Mints *amount* cash to the *recipient* account. Burns *amount* cash from the *account*. - **bond - Minting and burning of the bond token** -Mints *amount* bond to the *recipient* account. +Mints *amount* bond to the *recipient* account. Burns *amount* bond from the *account*. - - **share - Minting and burning of the share token** -Mints *amount* share to the *recipient* account. +Mints *amount* share to the *recipient* account. Burns *amount* share from the *account*. - **Treasure - Bond purchase and redemptions** Returns the oracle price of Algo Cash denominated in aUST. @@ -134,7 +125,6 @@ Mints *amount* Algo Cash, in exchange for *amount* Algo Bonds burnt. If the oracle price of Algo Cash is above (1+ε) aUST, mints *((ALC Oracle Price) - 1) * cashSupply* number of Algo Cash to either the Boardroom contract or the Treasury contract.If the Treasury's balance is below 1,000 ALC, the allocation is given to the Treasury, else give it to the Boardroom. - **Boardroom - Handling claims from the share** Stakes *amount* Algo Shares to Boardroom sends all prior accrued dividends to *account*. @@ -147,56 +137,59 @@ Claims all accrued dividends to *account*. When new cash is assigned to the Boardroom contract. Records the current block timestamp, the amount of new cash, and the current amount of total Shares staked. - **oracle - Retrieving the exchange rate between Algo Cash and aUST** -If 24 hours has passed since update() was last successfully executed, updates the time-weighted average price of Algo Cash. +If 24 hours has passed since update() was last successfully executed, updates the time-weighted average price of Algo Cash. Returns the amount of *output* tokens given in exchange for *input* number of *token* tokens ((Price of *token* token denominated in *output* tokens) * *input*). +### Ecosystem Fit - - - -### Ecosystem Fit Acala, aUSD is generated in a collateral way. Basis Cash (on Ethereum), shares are initialized by 'AMM + 2nd pool' which would cause dramatic infaltion, forcing Yeild Farmers to sell their assets to the second market. -## Team +## Team ### Team members + * Nick Hsu, Blockchain Expert and Team Leader -* Gang Chan, Full Stack Developer +* Gang Chan, Full Stack Developer * Gieno Miao, Crypto Expert and Blockchain Architect ### Contact + * **Contact Name:** Nick Hsu * **Contact Email:** nick_hsu@sina.com +### Legal Structure -### Legal Structure No legal Entity ### Team's experience + Nick has 16 years of software development experience and 5 years working in Blochain area as developer and product owner. Gang is now working as a freelancer. He is a full stack developer proficient in C++, Rust, React and Solidity. He has 3 years software development experience and 2 years smart contract development experience. ### Team Code Repos -* https://github.com/ReserveLabs/AlgoCash + +* ### Team LinkedIn Profiles + no +## Development Roadmap -## Development Roadmap ### Overview + * **Total Estimated Duration:** 6 weeks * **Full-time equivalent (FTE):** 1.5 * **Total Costs:** 5,000 DAI -### Milestone 1 Example — Implement Substrate Modules +### Milestone 1 Example — Implement Substrate Modules + * **Estimated Duration:** 7 weeks * **FTE:** 2 * **Costs:** 5,000 DAI @@ -206,15 +199,15 @@ no | 0 | License | Apache 2.0 / MIT / Unlicense | | 1 | Documentation | Specification of the background, components and working mechanism| | 2 | Smart Contract | AlgoCash smart contract repo. The smart contract can be deployed to any substrate chain with ink! pallet.| -| 3 | Tests |Unit Test and also we will test it on Canvas| +| 3 | Tests |Unit Test and also we will test it on Canvas| | 4 | Docker | A docker image with a Substrate chain for PoC| - - ## Future Plans + Shares token design for governance. We will build a DEX with PMM (Proactive Market Maker) algorithm. ## Community Engagement -We will reach DEX and Lending protocol communities to enlarge Algo Cash adoption. + +We will reach DEX and Lending protocol communities to enlarge Algo Cash adoption. diff --git a/applications/Apron_Network.md b/applications/Apron_Network.md index 5d2d1117c48..a7dbb253dc9 100644 --- a/applications/Apron_Network.md +++ b/applications/Apron_Network.md @@ -1,10 +1,9 @@ -# Open Grant Proposal +# Apron Network -* **Project Name:** Apron Network * **Team Name:** Apron Labs * **Payment Address:** 15tV6rQSwNgWQ1Z5pim2yJmELLvWNm5D4V -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview @@ -18,27 +17,22 @@ Maybe you are still thinking that it sounds terrible but no one can prove it. Le **On Nov. 11th, 2020, the API services from infura.io are down, and the idea of Apron Network comes out.** -The Apron Network is built by the Apron Labs powered by Substrate. It provides a Cross-chain Decentralized Infrastructure Services Network that will be used by blockchain node runners, DApp developers, the public chain community, and DApp users. Every DApp developer can discover the proper service provider for a specific blockchain through the decentralized infrastructure market on the Apron Network. The Apron Network can be run as a parachain of Polkadot. +The Apron Network is built by the Apron Labs powered by Substrate. It provides a Cross-chain Decentralized Infrastructure Services Network that will be used by blockchain node runners, DApp developers, the public chain community, and DApp users. Every DApp developer can discover the proper service provider for a specific blockchain through the decentralized infrastructure market on the Apron Network. The Apron Network can be run as a parachain of Polkadot. With the Apron Network, the DApp developers can find their API endpoint, node runners can provide infrastructure services to get profit and all the infrastructure services will be decentralized on the two-layers infrastructure service network. The Apron Network will guaranty there is no infura.io accident anymore! - - #### Integration The Apron Network can be run as a parachain on Polkadot, or an independent chain. The Apron Network contains Apron Node and Apron Market. The Apron Node is built with Substrate 2.0 Framework, and the OCW (Off-chain worker) will be included for API manage records. Apron Market consists of Apron Market Contracts and Apron Market Front End. The contracts will be implemented with Ink!, and the front-end will be built with polkadot.js. - - #### Team Interest -Most of the team members are DApp developers who suffer from the lacking of Ethereum API Endpoint and tightly rely on infura.io since we are not able to set up our full node due to funds. As we have known, most of the DApp developers have the same embarrassing situation as us. After shocked by the accident of infura.io, we are willing to build a decentralized infrastructure service network, and we name it the Apron Network. +Most of the team members are DApp developers who suffer from the lacking of Ethereum API Endpoint and tightly rely on infura.io since we are not able to set up our full node due to funds. As we have known, most of the DApp developers have the same embarrassing situation as us. After shocked by the accident of infura.io, we are willing to build a decentralized infrastructure service network, and we name it the Apron Network. With Substrate 2.0 Framework, we are able to build a customized blockchain network easily, and we have the ability to integrate an API Gateway to manage blockchain API services in Apron Node. With the Apron Network, the blockchain node runners can provide Infrastructure service easily and get profit through this decentralized infrastructure services network. +### Project Details - -### Project Details #### Architecture The Apron Network consists of **Apron Node**, **Arpon Market Contracts**, **Decentralized API Market**, and the **Apron SDK**. @@ -50,42 +44,32 @@ The Apron Network consists of **Apron Node**, **Arpon Market Contracts**, **Dece * Decentralized API Market lists all the API services registered and available for developers from the data in smart contracts. DApp developers search the API services according to their needs and choose the one with the proper price. * The Apron SDK makes the use of Apron Network easier. DApp developers can integrate this SDK in their app to dynamic switch blockchain entry-point according to their needs. - - #### Substrate / Polkadot Integration -The Apron Network can be run as a para-chain of Polkadot, and also can be run as an independent chain apart from Polkadot. +The Apron Network can be run as a para-chain of Polkadot, and also can be run as an independent chain apart from Polkadot. The whole network is built on top of the Substate 2.0 Framework, and OCW (off-chain worker) is used to report API usage statistics on which the billing relies. All the contracts will be implemented with Ink!, and the front-end of Decentralized API Market will be on top of polkadot.js. - - #### Scenarios * Node Runners - - ![img](https://raw.githubusercontent.com/Apron2050/graphics/main/Apron%20Node.jpg) -The above figure shows the role of each component act from the view of the blockchain node owner. To simply the scenario, we take an example. The para-chain node is running at the beginning, the Apron Node shown above is set up by the owner by staking some **$ANT**, and the Apron Node is accessible on the internet. The owner can configure Apron Node with the RPC entry point of the para-chain node, API access frequency, API access fee, and other limitations. After everything is configured, the Apron Node will be able to call the RPC interface of para-chain, and DApps will call the API through the Apron Node. The Apron Node calculates the API usage statistics of each caller, then stores this data through OCW (off-chain worker) on the chain for further billing. - - +The above figure shows the role of each component act from the view of the blockchain node owner. To simply the scenario, we take an example. The para-chain node is running at the beginning, the Apron Node shown above is set up by the owner by staking some **$ANT**, and the Apron Node is accessible on the internet. The owner can configure Apron Node with the RPC entry point of the para-chain node, API access frequency, API access fee, and other limitations. After everything is configured, the Apron Node will be able to call the RPC interface of para-chain, and DApps will call the API through the Apron Node. The Apron Node calculates the API usage statistics of each caller, then stores this data through OCW (off-chain worker) on the chain for further billing. * DApp Developers - - ![img](https://raw.githubusercontent.com/Apron2050/graphics/main/Apron%20Usage.jpg) For DApp developers, there are two components that will be used. One is the Decentralized API Market, the other one is the Apron SDK. Firstly, DApp developers search the API services in the API service repositories ( which is part of the Decentralized API Market) on the webpage. After finding the proper API service, the DApp developer will generate an API access key with the help of Apron Market Contracts. Finally, the DApp developer develops the DApp with the API access key to use the related API services. Of course, the DApp developer should pay the fee of using the API services according to the fee addressed by the API service provider. - #### Interface Specification The function provided by the pallet to report API usage statistics data is reportAPIUsage. + ``` 1. reportAPIUsage @@ -94,11 +78,11 @@ The function provided by the pallet to report API usage statistics data is repor - return: the calls number ``` -### Ecosystem Fit +### Ecosystem Fit -Infura.io is the typical infrastructure services provider that is totally centralized. +Infura.io is the typical infrastructure services provider that is totally centralized. -The Apron Network provides exactly the same API services as infura.io but in a decentralized way, thanks to Substrate 2.0 Framework which let us only focused on the logic on top of blockchain rather than re-develop a new blockchain. In the future, the Apron Network will provide a decentralized infrastructure services network. +The Apron Network provides exactly the same API services as infura.io but in a decentralized way, thanks to Substrate 2.0 Framework which let us only focused on the logic on top of blockchain rather than re-develop a new blockchain. In the future, the Apron Network will provide a decentralized infrastructure services network. ## Team :busts_in_silhouette: @@ -108,51 +92,60 @@ The Apron Network provides exactly the same API services as infura.io but in a d * Junjun - Full-stack Developer ### Contact -- https://apron.network -### Legal Structure +- + +### Legal Structure + No Legal Entity ### Team's experience -Toney - - Over 13 years of experiences in Software Development - - Software Engineer in MS - - Mobile Game Developer - - Blockchain Game Developer - - The Chief Tech Officier of the team which wins TRON Accelerator 2018 Game Rewards +Toney + +* Over 13 years of experiences in Software Development +* Software Engineer in MS +* Mobile Game Developer +* Blockchain Game Developer +* The Chief Tech Officier of the team which wins TRON Accelerator 2018 Game Rewards -Junjun - - Over 15 years of experiences in Software Development - - Former Senior Software Engineer in Lucent - - DApp Developer - - Full-stack Developer +Junjun + +* Over 15 years of experiences in Software Development +* Former Senior Software Engineer in Lucent +* DApp Developer +* Full-stack Developer ### Team Code Repos -* Apron Labs: https://github.com/apron-network + +* Apron Labs: ### Team LinkedIn Profiles + * [Toney](https://www.linkedin.com/in/yi-sui-297a9223/) -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: + ### Overview + * **Total Estimated Duration:** 3 months * **Full-time equivalent (FTE):** 4 * **Total Costs:** 0.73 BTC -### Milestone 1 Example — Implement Substrate Modules +### Milestone 1 Example — Implement Substrate Modules + * **Estimated Duration:** 3 months * **Full-time Equivalent (FTE):** 4 -* **Costs:** 0.73 BTC +* **Costs:** 0.73 BTC -In the first milestone, the features for the PoC will be implemented and tested by limited users. +In the first milestone, the features for the PoC will be implemented and tested by limited users. The following components will be included: * Apron Node * Apron Market Contracts -* Decentralized API Market / Front End -* Apron SDK +* Decentralized API Market / Front End +* Apron SDK | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -167,8 +160,6 @@ The following components will be included: | 6. | Article | We will write an article published on media channels. | | 7. | DAO | A Apron DAO will be created to handle the governance of the Decentralized API Market. | - - ## Future Plans Community Plan @@ -180,8 +171,6 @@ Community Plan * Bounty Program. * Publish articles on media channels to expose the Apron Network. - - Development Plan * The Apron Network will run as a parachain of the Kusama. @@ -191,10 +180,8 @@ Development Plan * In phase 3, provide decentralized quick node services. * Finally, our goal is to provide the infrastructure services network. - - -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: Currently we just start the first design of the Apron Network. -The project repo: https://github.com/apron-network +The project repo: diff --git a/applications/BCANN.md b/applications/BCANN.md index ce2af128727..b828a71a40b 100644 --- a/applications/BCANN.md +++ b/applications/BCANN.md @@ -1,28 +1,27 @@ -# W3F Open Grant Proposal +# BCANN ( The blockchain system for Assigned Names And Numbers ) > 🌏 This page is also available in [Chinese (中文)](./application-template-cn.md). -> +> > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. -> +> > See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/#pencil-process) on how to submit a proposal. -* **Project Name:** BCANN ( The blockchain system for Assigned Names And Numbers ) * **Proposer:** Witter Lee * **Payment Address:** 0x4575f459F79B6ed5Dd644aBCc64affCc4c680DE3 * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/353#issuecomment-946463960) - -## Project Overview : +## Project Overview ### Overview + BCANN is a protocol of assigned names & numbers & crypto-currency addresses for multi-chain. ### Background + DNS is the infrastructure of the Internet,an efficient resource addressing method. But DNS has some common problems like below - 1.Domain name hijacking 2.DNS cache pollution 3.DDOS attack @@ -34,21 +33,20 @@ 2.Prevent DNS cache pollution by distributed ledger for Name Services 3.DDOS can not attack all decentralized name service nodes - There are some decentralized DNS projects, such as Namecoin, ENS, etc. These projects solve many central service problems, but the boundary of the blockchain makes DNS unable to act on the blockchain outside of itself. The Polkadot cross-chain ecosystem breaks the boundaries between the blockchain and makes it possible for the deentralized DNS, and that's why we created this project. -### Project Details +### Project Details [architecture](https://drive.google.com/file/d/1eD3fqQ0p7osblX1x-iW3hPLhIWG3R4Lv/view?usp=sharing) The BCANN protocol will allow parachains to quickly obtain the complete functions of decentralized domain names through the Polkadot parachain module, and meet the needs of developers on the parachain for the name services's functions. - #### Interface Specification Main interface (Users can implement the Resolver by themselves for extension) + ``` 1. name registry /** @@ -156,7 +154,7 @@ Main interface (Users can implement the Resolver by themselves for extension) ``` -### Ecosystem Fit +### Ecosystem Fit There is a [deeper.network](https://github.com/w3f/Open-Grants-Program/blob/master/applications/deeper_network.md) project that includes decentralized DNS. There are several diferences worth highligting: @@ -164,13 +162,11 @@ There is a [deeper.network](https://github.com/w3f/Open-Grants-Program/blob/mast There is a [ens](https://ens.domains/) project. There are several diferences worth highligting: -*ENS is a smart contract deployed on ETH,BCANNN is the infrastructure of the parachain, which will be released as a substrate runtime module library. - +*ENS is a smart contract deployed on ETH,BCANNN is the infrastructure of the parachain, which will be released as a substrate runtime module library. There is a [Nicks Module](https://github.com/paritytech/substrate) project. There are several diferences worth highligting: *Nicks Module is a module that keep track of account names on-chain.BCANN provides a complete domain name service and address mapping service. - There is a [substrate-names](https://github.com/xaya/substrate-names/) project. There are several diferences worth highligting: @@ -180,11 +176,10 @@ There is a [substrate-name-service](https://github.com/hskang9/substrate-name-se *Support of Substrate-name-service for subdomains is not good enough, and only supports IPV4. This is just a sample project and the updating has been stopped. BCANN provides complete domain name/subdomain name service and address mapping service. -Name services is an infrastructure for blockchain ecosystem. In the blockchain world, the human-readable name is the effective identification for hash, addresses, and other items, which improves the usability. +Name services is an infrastructure for blockchain ecosystem. In the blockchain world, the human-readable name is the effective identification for hash, addresses, and other items, which improves the usability. Usage scenarios: - a. Human-readable identity for decentralized social media b. Human-readable identity for decentralized email c. Human-readable identity for the address to send asset @@ -193,57 +188,63 @@ Usage scenarios: BCANNN will create a name service protocol on polkadot parachain. As a basic protocol of the name service, BCANNN will have built-in support for name/subname registry and resolver,and it shall support existing blockchain domain names, such as .eth, .luxe, etc., through adapter contract. That means users can use BCANNN as a common resolver for all blockchain domain to query/update name services records. - ## Team :busts_in_silhouette: ### Team members + * Witter Lee * Chak Zhou * Andy An ### Contact + * **Contact Name:** Witter Lee * **Contact Email:** lwt@msn.cn -### Legal Structure +### Legal Structure + - No.2588 Hongmei South Road, Minhang District, Shanghai -- Shanghai Blockchain Network Technology Co., Ltd. +* Shanghai Blockchain Network Technology Co., Ltd. ### Team's experience + Witter Lee : Full stack engineer with 12+ years of experience 7 years of experience in the blockchain industry - 4 years of experience in smart contract + 4 years of experience in smart contract 2013~2014 RippleChina.cn's CTO 2014~2016 fullcoin.com exchange's CTO 2016~2018 19800.com exchange CEO & CTO - 2018~2020 azex exchange CEO + 2018~2020 azex exchange CEO Chak Zhou : Full stack engineer with 10+ years experience 4 years of experience in the blockchain industry - 2 years of experience in smart contract development + 2 years of experience in smart contract development 2010~2014 Senior engineer of Travel e-commerce 2014~2016 Senior engineer of cross-border e-commerce 2017~2018 19800.com exchange CTO - 2018~2020 azex exchange CTO + 2018~2020 azex exchange CTO Andy An : Senior engineer engineer with 10 + years experience 2 years of experience in the blockchain industry - 2 years of experience in smart contract + 2 years of experience in smart contract 2010~2016 Senior engineer of alipay 2016~2018 Senior engineer of 19800.com exchange 2018~2020 Senior engineer of azex exchange We come from a long-term cooperation team, we have 5+ years experience in blockchain industry, like blockchain technology , smart contract development, We have 2+ years of experience in researching on the ens project. -## Development Roadmap +## Development Roadmap + ### Overview + * **Total Estimated Duration:** 12 weeks * **Total Costs:** 10,000.00 DAI ### Milestone 1: Initial implementation, name service registry and name resolver + * **Estimated Duration:** 4 weeks * **Full-time equivalent (FTE):** 2 * **Costs:** 5,000 DAI @@ -252,7 +253,7 @@ We come from a long-term cooperation team, we have 5+ years experience in blockc | ------------- | ------------- | ------------- | | 0a. | License | MIT | | 0b. | Documentation | We will provide inline documentation of the code and basic tutorials, which will explain how to use name services| -| 0c. | Testing coverage | The code will have unit-test coverage (min. 90%) to ensure functionality and robustness. We will describe how to run these tests in the guide.| +| 0c. | Testing coverage | The code will have unit-test coverage (min. 90%) to ensure functionality and robustness. We will describe how to run these tests in the guide.| | 1. | Module design| The name/sub-name will enable NFT support for names transfer/rental services | | 2. | Customizable Resolver | We will implement methods to set up custom resolver| @@ -261,9 +262,10 @@ a. Official website with project introduction b. ParaChain frame source code, protocol introduction document and module deployment document c. Unit testing and test documentation +### Milestone 2: Example of name services dapp -### Milestone 2: Example of name services dapp [mock-ups for milestone 2](https://org.modao.cc/app/4447109c463ec3a36043cb54e1edd7fafcc01c2c?simulator_type=device&sticky) + * **Estimated Duration:** 4 weeks * **Full-time equivalent (FTE):** 3 * **Costs:** 5,000 DAI @@ -273,13 +275,13 @@ c. Unit testing and test documentation | 0a. | License | Apache 2.0 | | 0b. | Documentation |We will provide documentation on how to get a name/subname, and how to use your name/subname for crypto address resolve | | 0c. | Testing Guide | We will provide users with a test name services, and users can get a 30-day test period for a name/subname | -| 1. | ns dapp| We will implement a dapp to get/manage/transfer your name/subname. +| 1. | ns dapp| We will implement a dapp to get/manage/transfer your name/subname. We will implement a dapp at this milestone. The deliverable part includes: a. Dapp for getting/managing/transferring your name/subname b. Dapp for getting/managing/transferring your name/subname for test purpose (free name/subname) ## Future Plans - - 1. We will create a mail system for name/subname which offers common mail service with crypto currency sending service + + 1. We will create a mail system for name/subname which offers common mail service with crypto currency sending service 2. We will create a BCANN parachain for each parachain as the superset of the registry data, it can provide developers with one-stop domain name registry and resolve services diff --git a/applications/Banksy_Finance.md b/applications/Banksy_Finance.md index ad722469931..da109029248 100644 --- a/applications/Banksy_Finance.md +++ b/applications/Banksy_Finance.md @@ -1,6 +1,4 @@ -# Open Grant Proposal - -* **Project:** Banksy Finance +# Banksy Finance * **Proposer:** Clink Li diff --git a/applications/CESS.md b/applications/CESS.md index adb24f866cf..cbdf1084ba5 100644 --- a/applications/CESS.md +++ b/applications/CESS.md @@ -1,22 +1,17 @@ -# W3F Open Grant Proposal - - -* **Project Name:** Cumulus Encrypted Storage System (CESS) -* **Team Name:** CESS LAB -* **Payment Address:** 0x378D889a6e66996C9Eda86D20D7E6adE666ce167(USDT) -* **Level:** 1 +# Cumulus Encrypted Storage System (CESS) +- **Team Name:** CESS LAB +- **Payment Address:** 0x378D889a6e66996C9Eda86D20D7E6adE666ce167(USDT) +- **Level:** 1 ## Project Overview :page_facing_up: - ### Overview -* Tag line: An infrastructure for a blockchain-based decentralized cloud data network. -* Brief description: Cumulus Encrypted Storage System (CESS) is dedicated to develop a new global decentralized cloud data storage platform – a blockchain-based network infrastructure that is transparent, efficient, and equal opportunity to all members of the global community. CESS encourages excess or under-utilized resources as nodes to join CESS’s unrestricted expandable network via the token economy incentive method. Each node joins the CESS peer-to-peer network by contributing data storage resources, computational resources, or network bandwidth. Built on our state-of-the-art virtualization and cloud computing technologies, CESS organizes and manages the participating resources providing clients with secure, high performance, and boundless cloud data storage services. Furthermore, the CESS protocol enables interconnection of network nodes, to build a large decentralized cloud storage system that supports up to 100PB storage scale to meet the demand of enterprise level data storage. CESS will adopt a phased approach to implement the above goals. -* Indication 1: With the goal of entering Polkadot ecosystem, CESS will build a blockchain system based on Substrate directly, and plans to develop custom pallets on FRAME. In the future, CESS will consider integrating to Polkadot in the form of Parachain to create a new decentralized cloud storage ecosystem, establish a large-scale distributed storage network. -* Indication 2: With rapid advances of new computing technologies such as big data and machine learning, the value of humanity’s digital assets, the so-called “Digital Gold”, are being discovered. Explosively growing amount of data in cyberspace calls for new technologies of secure data storage and efficient data sharing. The challenges are to achieve secure storage, efficient sharing, and trading with data owner’s rights protection, but current solutions are complex and worrisome. Distributed storage networks can better drive the arrival of Web3.0 and are one of the underlying technical infrastructure of Web3.0. - +- Tag line: An infrastructure for a blockchain-based decentralized cloud data network. +- Brief description: Cumulus Encrypted Storage System (CESS) is dedicated to develop a new global decentralized cloud data storage platform – a blockchain-based network infrastructure that is transparent, efficient, and equal opportunity to all members of the global community. CESS encourages excess or under-utilized resources as nodes to join CESS’s unrestricted expandable network via the token economy incentive method. Each node joins the CESS peer-to-peer network by contributing data storage resources, computational resources, or network bandwidth. Built on our state-of-the-art virtualization and cloud computing technologies, CESS organizes and manages the participating resources providing clients with secure, high performance, and boundless cloud data storage services. Furthermore, the CESS protocol enables interconnection of network nodes, to build a large decentralized cloud storage system that supports up to 100PB storage scale to meet the demand of enterprise level data storage. CESS will adopt a phased approach to implement the above goals. +- Indication 1: With the goal of entering Polkadot ecosystem, CESS will build a blockchain system based on Substrate directly, and plans to develop custom pallets on FRAME. In the future, CESS will consider integrating to Polkadot in the form of Parachain to create a new decentralized cloud storage ecosystem, establish a large-scale distributed storage network. +- Indication 2: With rapid advances of new computing technologies such as big data and machine learning, the value of humanity’s digital assets, the so-called “Digital Gold”, are being discovered. Explosively growing amount of data in cyberspace calls for new technologies of secure data storage and efficient data sharing. The challenges are to achieve secure storage, efficient sharing, and trading with data owner’s rights protection, but current solutions are complex and worrisome. Distributed storage networks can better drive the arrival of Web3.0 and are one of the underlying technical infrastructure of Web3.0. ### Project Details @@ -24,102 +19,108 @@ We expect the teams to already have a solid idea about your project's expected f Mockups/designs of any UI components -* Global nodes: Display the global map and the number of global nodes of distributed storage network, and mark the location distribution of nodes according to coordinates; Display node list. +- Global nodes: Display the global map and the number of global nodes of distributed storage network, and mark the location distribution of nodes according to coordinates; Display node list. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img1.png) -* My cloud disk: Personal storage space to view the files uploaded to the storage network; The list can be sorted by upload time, file name, file type and file size; Supports file download, share, property setting, deletion and other operations. +- My cloud disk: Personal storage space to view the files uploaded to the storage network; The list can be sorted by upload time, file name, file type and file size; Supports file download, share, property setting, deletion and other operations. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img2.png) -* File upload: Select the files to be stored and set the relevant storage parameters. +- File upload: Select the files to be stored and set the relevant storage parameters. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img3.png) -* Search for file: Search the whole network through keywords, and download the search results. +- Search for file: Search the whole network through keywords, and download the search results. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img4.png) Documentation of core components, protocols, architecture, etc. to be deployed -* CESS is a high-speed, secure, scalable and decentralized cloud storage system. It can handle tens of thousands of transactions per second through parallel technology. Through Data slicing technology, it can achieve the secure storage of massive data, and it has the functions of Data confirmation and Data rights protection, which provides powerful data service ability. It provides DAPP with unlimited scalable storage capacity and perfect Data rights protection capability. +- CESS is a high-speed, secure, scalable and decentralized cloud storage system. It can handle tens of thousands of transactions per second through parallel technology. Through Data slicing technology, it can achieve the secure storage of massive data, and it has the functions of Data confirmation and Data rights protection, which provides powerful data service ability. It provides DAPP with unlimited scalable storage capacity and perfect Data rights protection capability. + +- Data storage workflow: When a client requests to store a data file, the CESS platform pre-processes the data file to obtain and store its meta-data and data fingerprints. The pre-process software also performs data file replication and fault tolerant erasure coding. The meta-data includes info of data owner, data keywords, and etc. The data fingerprints are for subsequent data rights confirmation. + +
+ +- CESS client-platform interactions: A typical CESS data client and platform interaction flow is as follows: first, a data storage client interrogates CESS chain to get current storage price. The client then places an order for his/her data file via extrinsics on blockchain. Once the payment is made and order is approved, the client then uploads the data file using API provided by CESS platform. The data file is not directly uploaded to storage nodes, instead it is uploaded to a CESS storage scheduling node. The scheduling nodes are the ones with secure hardware environment (Trusted Execution Environment or TEE) and the data file will be pre-processed, encrypted, and sharded. Finally, the scheduling node distributes data segments to storage nodes to store. CESS storage miners do not make deal directly with clients, and they get rewarded from CESS system by providing storage space. Miners’ storage resources are uniformly managed by CESS system, which fairly distributes data files. Miners have the responsibility to maintain the integrity of clients’ data. Any malicious behavior will be punished (CESS token deduction). + +
-* Data storage workflow: When a client requests to store a data file, the CESS platform pre-processes the data file to obtain and store its meta-data and data fingerprints. The pre-process software also performs data file replication and fault tolerant erasure coding. The meta-data includes info of data owner, data keywords, and etc. The data fingerprints are for subsequent data rights confirmation. -
+- Overall system architecture: CESS adopts a layered and loosely coupled system architecture, which is divided into blockchain service layer, distributed storage resource layer, distributed content delivery layer and application layer. -* CESS client-platform interactions: A typical CESS data client and platform interaction flow is as follows: first, a data storage client interrogates CESS chain to get current storage price. The client then places an order for his/her data file via extrinsics on blockchain. Once the payment is made and order is approved, the client then uploads the data file using API provided by CESS platform. The data file is not directly uploaded to storage nodes, instead it is uploaded to a CESS storage scheduling node. The scheduling nodes are the ones with secure hardware environment (Trusted Execution Environment or TEE) and the data file will be pre-processed, encrypted, and sharded. Finally, the scheduling node distributes data segments to storage nodes to store. CESS storage miners do not make deal directly with clients, and they get rewarded from CESS system by providing storage space. Miners’ storage resources are uniformly managed by CESS system, which fairly distributes data files. Miners have the responsibility to maintain the integrity of clients’ data. Any malicious behavior will be punished (CESS token deduction). -
+
-* Overall system architecture: CESS adopts a layered and loosely coupled system architecture, which is divided into blockchain service layer, distributed storage resource layer, distributed content delivery layer and application layer. -
+- CESS MDRC mechanism workflow: CESS have designed a unique **Multi-format Data Rights Confirmation Mechanism (MDRC)**, which extracts data fingerprint from each data file to generate data certificate ID. By comparing similarities between data fingerprints, the system identifies data lineages of data files, and may take appropriate actions to prevent possible violations, and to provide strong evidences for owners’ data rights protection. -* CESS MDRC mechanism workflow: CESS have designed a unique **Multi-format Data Rights Confirmation Mechanism (MDRC)**, which extracts data fingerprint from each data file to generate data certificate ID. By comparing similarities between data fingerprints, the system identifies data lineages of data files, and may take appropriate actions to prevent possible violations, and to provide strong evidences for owners’ data rights protection. -
+
### Ecosystem Fit CESS is a distributed cloud data network with user friendly ledgers, novel consensus mechanism, multiple data authenticity proof schemes, and reliable network infrastructure. CESS offers data storage service with the advantages of low cost, privacy protection, security and robustness. With the implementation of CESS data confirmation and proxy re-encryption technology, CESS provides Web3.0 clients and DAPPs with trustworthy, secure and reliable data rights protection. Compared to the similar projects in the Polkadot ecosystem including Ocean, DataHighway and Bluzelle, CESS storage service features: -* Encrypted data storage -* Multiple copies (3 copies by default, more upon request) -* Sharded and distributed on multiple nodes -* Highly scalable storage space -* Transactions secured by CESS blockchain -* Data rights protection for data owners -* Competitive cost + +- Encrypted data storage +- Multiple copies (3 copies by default, more upon request) +- Sharded and distributed on multiple nodes +- Highly scalable storage space +- Transactions secured by CESS blockchain +- Data rights protection for data owners +- Competitive cost ## Team :busts_in_silhouette: ### Team members -* Joseph Li -* Jinghong Zeng +- Joseph Li +- Jinghong Zeng ### Contact -* **Contact Name:** Jessie Dai -* **Contact Email:** jessie@cess.cloud -* **Website:** http://cess.cloud +- **Contact Name:** Jessie Dai +- **Contact Email:** jessie@cess.cloud +- **Website:** ### Legal Structure -* **Registered Address:** 22 St Leonard's Ave, Lostock, Bolton BL6 4JE, England -* **Registered Legal Entity:** Paul David Humphreys +- **Registered Address:** 22 St Leonard's Ave, Lostock, Bolton BL6 4JE, England +- **Registered Legal Entity:** Paul David Humphreys ### Team's experience -* Team CESS +- Team CESS -CESS technical team members have an affluent understanding of technology and have been involved in internationally renowned cloud storage companies as essential technical development members. +CESS technical team members have an affluent understanding of technology and have been involved in internationally renowned cloud storage companies as essential technical development members. The background of our team members includes but not limited to cloud computing and storage, involved in cloud related PaaS and SaaS products research and development; unique insights into the network development, cryptography algorithm implementation, and performance optimization; comprehensive knowledge of public chain and played a major role in the development of public chain focusing on the delivery of commercial applications. For the past two years, CESS core team members have been developing and building a stable decentralized cloud storage service atop the distributed resources to surmount the security risks presented in the current centralized storage platform. The members are working in the UK, China, and India locations with the commitment creating a decentralized cloud storage data network for commercial use. -* Joseph Li + +- Joseph Li Joseph Li brings to our operations 24 years of experiences as a Principal Network Engineer managing and supporting large-scale networks on a global scale. Amongst Joseph’s numerous achievements was the IP infrastructure conversion for a network of over 900 nodes and his major accomplishments within the field of VPN. -* Jinghong Zeng + +- Jinghong Zeng Jinghong Zeng served more than 20 years with a global telecommunications cooperation as a Senior System Architect and Software Engineer, she has proven skills in data warehousing, data processing within distributed systems and a solid understanding of Blockchain. ### Team Code Repos -* https://github.com/Cumulus2021/CumulusSystem -* https://github.com/Cumulus2021/Whitepaper +- +- ## Development Roadmap :nut_and_bolt: - ### Overview -* **Total Estimated Duration:** 4 months -* **Full-Time Equivalent (FTE):** 2 -* **Total Costs:** 8,000 USD +- **Total Estimated Duration:** 4 months +- **Full-Time Equivalent (FTE):** 2 +- **Total Costs:** 8,000 USD ### Milestone 1: Implement Substrate Modules -* **Estimated Duration:** 2 months -* **FTE:** 2 -* **Costs:** 4,000 USD +- **Estimated Duration:** 2 months +- **FTE:** 2 +- **Costs:** 4,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -132,12 +133,11 @@ Jinghong Zeng served more than 20 years with a global telecommunications coopera | 1c. | Substrate module: Storage Miner | We will create a Substrate module that will process and upload user data, and support Integrity verification. | | 2. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain. | - ### Milestone 2: Implement Storage Mining -* **Estimated Duration:** 1 month -* **FTE:** 2 -* **Costs:** 2,000 USD +- **Estimated Duration:** 1 month +- **FTE:** 2 +- **Costs:** 2,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -146,16 +146,15 @@ Jinghong Zeng served more than 20 years with a global telecommunications coopera | 0c. | Testing Guide | The code will have unit-test coverage (min. 80%) to ensure functionality and robustness. In the guide we will describe how to run these tests. | | 0d. | Article/Tutorial | We will publish an article and a tutorial that explains the work done as part of the grant. | | 1a. | Stacked DRG Library | We will create a library for proving and verifying transactions, compatible with the substrate pallet. | -| 1b. | zk-SNARK proofs | We will implement the algorithm to process the proof results from stacked DRG library. | -| 2. | Substrate module: Segment Book | Develop pallet implement function of storage mining. | -| 3. | Miner Client | Interactive with pallet for storage mining to implement mining supporting services. | - +| 1b. | zk-SNARK proofs | We will implement the algorithm to process the proof results from stacked DRG library. | +| 2. | Substrate module: Segment Book | Develop pallet implement function of storage mining. | +| 3. | Miner Client | Interactive with pallet for storage mining to implement mining supporting services. | ### Milestone 3: Implement and Integrate CESS Applications -* **Estimated Duration:** 1 month -* **FTE:** 2 -* **Costs:** 2,000 USD +- **Estimated Duration:** 1 month +- **FTE:** 2 +- **Costs:** 2,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -164,11 +163,10 @@ Jinghong Zeng served more than 20 years with a global telecommunications coopera | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. | | 0d. | Article/Tutorial | We will publish an article and a tutorial that explains the work done as part of the grant. | | 1. | Cryptographic modules | We will implement the cryptographic modules including inner product functional encryption and the associated zero-knowledge proof for storage proof. | -| 2. | UI Modules | We will design a user-friendly UI that supports both PC and mobile. | -| 3. | File processing | We provide abundant file operation services, including file upload, download, share, delete, etc. | -| 4. | Benchmark | Perform unit tests on the individual algorithms to ensure system safety. | -| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain. | - +| 2. | UI Modules | We will design a user-friendly UI that supports both PC and mobile. | +| 3. | File processing | We provide abundant file operation services, including file upload, download, share, delete, etc. | +| 4. | Benchmark | Perform unit tests on the individual algorithms to ensure system safety. | +| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain. | ## Future Plans diff --git a/applications/Cere_Turnkey_Private_Blockchain_Network.md b/applications/Cere_Turnkey_Private_Blockchain_Network.md index 06ada64d3a4..ecfed31b2ff 100644 --- a/applications/Cere_Turnkey_Private_Blockchain_Network.md +++ b/applications/Cere_Turnkey_Private_Blockchain_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Turn-key Private Standalone Blockchain Network -* **Project:** Turn-key Private Standalone Blockchain Network * **Proposer:** [Cere-Network](https://github.com/Cerebellum-Network) * **Payment Address:** 1BbyAGddobdPgNo9c63xsRnwK5hen8pV7F diff --git a/applications/Coinversation.md b/applications/Coinversation.md index 12aa0aa3495..bbefc75bf23 100644 --- a/applications/Coinversation.md +++ b/applications/Coinversation.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Coinversation Protocol -* **Project:** Coinversation Protocol * **Proposer:** [coin-pro](https://github.com/coin-pro) * **Payment Address:** 3FX6TD7Qm255foMg7xZStZNAfpLvDai5P8 * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/233#issuecomment-886535171) diff --git a/applications/DICO.md b/applications/DICO.md index 1495294cbc5..133e0edd372 100644 --- a/applications/DICO.md +++ b/applications/DICO.md @@ -1,12 +1,9 @@ -# DICO Open Grant Proposal +# DICO - -* **Project Name:** DICO * **Team Name:** DICO Team * **Payment Address:** 0x0211ae8881a3a0a41150627da07c900b78144a84(USDT) * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/636#issuecomment-1144901144) - ## Project Overview The `DICO` is to create a decentralized and governable ICO platform for the Polkadot/Kusama ecology. Our platform will allow entrepreneurs to quickly find investors. In a word: Be a platform to link ideas and capital. @@ -26,24 +23,20 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy * *KYC*,*ICO*,*DAO* and *Swap* modules are built on substrate runtime. they complete the basic user interaction logic. * *Oracle* enabled off-chain worker to query the current price feed of the platform or other tokens. - ### Project Details #### Mockups and UI components -

- #### ICO

-

@@ -60,12 +53,10 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy

-

- #### KYC

@@ -76,7 +67,6 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy

- #### DAO

@@ -87,10 +77,8 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy

- #### Swap -

@@ -103,7 +91,6 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy

- ### Ecosystem Fit * Where and how does your project fit into the ecosystem? @@ -118,7 +105,6 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy > Be a platform to link ideas and capital. - * Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? * If so, how is your project different? *coinlist*，A token financing platform, all the mainstream virtual currencies above can be traded and financed. It provides token financing, but does not provide the funds needed by early creator and the control of the entire project cycle. @@ -136,7 +122,7 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy * **Contact Name:** gogomath * **Contact Email:** gogomath@outlook.com -* **Website:** https://dico.io/ +* **Website:** ### Legal Structure @@ -147,11 +133,11 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy ### Team's experience -*Daniel*: Daniel is currently a venture investor at [WEB3 Venture Capital](https://web3.vc/#/). Daniel previously is a solidity/EOS engineer. +*Daniel*: Daniel is currently a venture investor at [WEB3 Venture Capital](https://web3.vc/#/). Daniel previously is a solidity/EOS engineer. *gogomath*: gogomath is the CTO of the team and has 10 years of software development experience. The fields involved are big data, machine learning, SAAS, devops. And familiar with eth/near/polkadot in the field of digital encryption development. -*cf*: cf is a full stack engineer with five years of development experience. and familiar with Go/Rust/Java/Python/Javascript/Typescript +*cf*: cf is a full stack engineer with five years of development experience. and familiar with Go/Rust/Java/Python/Javascript/Typescript *tokggo*: tokggo is the test/devops engineer of the team, he is very good at writing various documents.and has 6 years of development experience. @@ -161,25 +147,20 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy ### Team Code Repos -* https://github.com/DICO-TEAM/dico-chain - +* ## Development Status :open_book: - -*interface iterations and resource*: https://github.com/DICO-TEAM/resources +*interface iterations and resource*: ## Development Roadmap :nut_and_bolt: - ### Overview - * **Total Estimated Duration:** 1 months * **Full-Time Equivalent (FTE):** 6 FTE * **Total Costs:** 10k USD - ### Milestone 1 — Implement KYC, ICO, DAO Modules * **Estimated duration:** 1 month @@ -192,9 +173,9 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy | 1.a | Substrate module: KYC pallet | KYC pallet Includes identity authentication service(IAS), KYC users, and swordholder. responsible for providing users with a decentralized KYC certification service.and provide area authentication of the account.Detailed explanation is described [here](https://github.com/DICO-TEAM/dico-chain/tree/main/pallets/kyc/README.md)| | 1.b | Substrate module: ICO pallet | Apply for ICO and council review for the project party. Detailed explanation is described [here](https://github.com/DICO-TEAM/dico-chain/tree/main/pallets/ico/README.md)| | 1.c | Substrate module: DAO pallet | Integrate governance with the ICO module to provide governance logic for the opening and closing of the ICO of the project. Detailed explanation is described [here](https://github.com/DICO-TEAM/dico-chain/tree/main/pallets/dao/README.md)| -| 2.a. | Integration with front-end(dapp) |integrate our existing front end to the finalized module.| +| 2.a. | Integration with front-end(dapp) |integrate our existing front end to the finalized module.| | 2.b | Tutorial| We will create an screenshot tutorial and a demo video that will explain how users can start using the platform for KYC and ICO. | -| 3. | Testing Guide/Documentation | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests and add inline documentation of the code. | +| 3. | Testing Guide/Documentation | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests and add inline documentation of the code. | | 4. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.| | 5. | Docker-compose | We will provide a docker-compse.yml that can be used to test parachain version node delivered with this milestone.in this version, users will be invited to this testnet | -| 6. | Lending module(research oriented)| Innovation combining ICO and borrowing/lending. In our 2.0 version, we hope to introduce an innovation combining lending and ICO. The goal is to make ICO more diversified through borrowing/lending. Through the logic of borrowing/lending, and participation in ICO, the participants will be more diverse. At the same time, in the 2.0 testnet, we will let users participate in this pallet. According to the test results, publish a blog to show the test results.| +| 6. | Lending module(research oriented)| Innovation combining ICO and borrowing/lending. In our 2.0 version, we hope to introduce an innovation combining lending and ICO. The goal is to make ICO more diversified through borrowing/lending. Through the logic of borrowing/lending, and participation in ICO, the participants will be more diverse. At the same time, in the 2.0 testnet, we will let users participate in this pallet. According to the test results, publish a blog to show the test results.| diff --git a/applications/DKSAP.md b/applications/DKSAP.md index 308422e8e06..676f7738745 100644 --- a/applications/DKSAP.md +++ b/applications/DKSAP.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# DKSAP -- **Project Name:** DKSAP - **Team Name:** DKSAP - **Payment Address:** 0xf4f463B9A0ADa68536423121e7Bf9E559ce54fAf(Ethereum ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 diff --git a/applications/DNFT.md b/applications/DNFT.md index 75bfab316e8..082d5606a55 100644 --- a/applications/DNFT.md +++ b/applications/DNFT.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# DNFT Protocol -* **Project:** DNFT Protocol * **Proposer:** [DNFT](https://github.com/DNFT-Team) * **Payment Address:** 1Atc7JjqeSw1PwxCsSr8KPHEKDoRfh5ERF * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/213#issuecomment-918946371) diff --git a/applications/Dante_Network.md b/applications/Dante_Network.md index e15ded2f4d4..5746535e7fa 100644 --- a/applications/Dante_Network.md +++ b/applications/Dante_Network.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Dante Network -- **Project Name:** Dante Network - **Team Name:** Dante Network - **Payment Address:** 0xc92314a5f62FA54b272612804C9Ac70AC139F7B0 (Ethereum ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Datagen_Project.md b/applications/Datagen_Project.md index 70f449a7e52..e3823ed743f 100644 --- a/applications/Datagen_Project.md +++ b/applications/Datagen_Project.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Datagen Project -- **Project Name:** Datagen Project - **Team Name:** B-Datagray - **Payment Address:** 0x330330C5F676cec700CB30aF9E37D3012f525AeE - Ethereum Network - USDC - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 @@ -11,7 +10,7 @@ B-Datagray’s Datagen project concerns the development of a decentralized infrastructure for CPU/GPU cloud computing, in chain, through different blockchain components. -The Datagen infrastructure requires the creation of a Substrate-based blockchain with some key features: low latency time, high efficiency (compatibly with the decentralized nature of the network), high degree of decentralization (higher than a traditional PoS would allow) of the physical hardware providing the cloud computing (therefore requiring a customized consensus protocol) and in-chain (or near-in-chain) computation (no off-chain based solutions). +The Datagen infrastructure requires the creation of a Substrate-based blockchain with some key features: low latency time, high efficiency (compatibly with the decentralized nature of the network), high degree of decentralization (higher than a traditional PoS would allow) of the physical hardware providing the cloud computing (therefore requiring a customized consensus protocol) and in-chain (or near-in-chain) computation (no off-chain based solutions). The Datagen infrastructure primarily want to serve: privacy friendly search engines and browsers, decentralized Web3 games and other ones (for example decentralizing the hardware layer of PoS blockchains, typically hosted on AWS and similar, etc…). @@ -21,40 +20,40 @@ B-Datagray team is really interested in creating this solution because we think ### Project Details -Architecture: The infrastructure will rely on two main pillars: a fast and independent substrate based blockchain (Fast Blockchain FB) and a slower but more resilient Polkadot/ Kusama parachain (Heavy Blockchain HB). +Architecture: The infrastructure will rely on two main pillars: a fast and independent substrate based blockchain (Fast Blockchain FB) and a slower but more resilient Polkadot/ Kusama parachain (Heavy Blockchain HB). ![datagen_infrastructor_diagram](https://i.imgur.com/3VDy0Wm.png) -The actual cloud computing will happen in our FB Datagen (substrate based). The reason for which we are having the cloud computing in an independent blockchain is that we need our blocktime to be lower than Polkadot’s / Kusama’s blocktime (ideally < 1sec when the infrastructure is ready) to be able to provide cloud computing to most Web3 gaming applications and privacy-friendly search engines. +The actual cloud computing will happen in our FB Datagen (substrate based). The reason for which we are having the cloud computing in an independent blockchain is that we need our blocktime to be lower than Polkadot’s / Kusama’s blocktime (ideally < 1sec when the infrastructure is ready) to be able to provide cloud computing to most Web3 gaming applications and privacy-friendly search engines. While, what happens in this HB will be asynchronously and randomly verified in the Parachain. -We adopt the relativistic point of view of the data-flow from the user to explain the underlying process. +We adopt the relativistic point of view of the data-flow from the user to explain the underlying process. The user connects to the network (typically through the API of the application provider that is using the Datagen Infrastructure), than the user goes through the so called ECHO procedure: he/she sends a package of raw data to be processed by the network and the first validator that answers correctly to him/her is paired to the user on a one to one basis (this is the only PoW heavy-like process that is happening in the whole infrastructure and is done to pair any user with the most efficient validator to him/her, starting from the assumption that by geography and/or specific application in use and/or other factors not all the users and the same validators have the same latency time). -The user is now paired to a specific validator (for a given amount of time -in the magnitude of some weeks-; after that given amount of time the user will send periodically other ECHOs, to allow to reassess the efficiency of the validators in the network). +The user is now paired to a specific validator (for a given amount of time -in the magnitude of some weeks-; after that given amount of time the user will send periodically other ECHOs, to allow to reassess the efficiency of the validators in the network). The user (through the Application Provider’s API) sends raw data both to the paired validator in the FB Datagen and to the HB Polkadot’s Parachain. The validator in the FB must solve the raw computational request and turn it into a hash, within the blocktime, so, the hashed data must propagate in the whole FB, but there is no need for the raw data to be processed multiple times (like in a PoW) in the FB. So, what is verifiably shared by the validators of the FB is the series of hashes and not the reiteration of the same computational process. The FB, as a whole, is so behaving more alike a PoS blockchain than a PoW. -Since the blocktime of the Parachain is longer than the blocktime of the FB, both the raw data from the user and the hashed data from the validator are sent to the Parachain in an asynchronous way (typically it could be every 10 to 30 blocks of the FB). +Since the blocktime of the Parachain is longer than the blocktime of the FB, both the raw data from the user and the hashed data from the validator are sent to the Parachain in an asynchronous way (typically it could be every 10 to 30 blocks of the FB). The parachain is not re-computing all the raw and the hashed data, for the moment is just storing them in a verifiable way. ![datagen_deep_infrastructure_diagram](https://i.imgur.com/w0obsru.png) -**Example**: `raw data X` came from `user A`, resulting in `hash Y` from `validator A`. Randomly, the Parachain extracts some computational problems to be double-checked. For example, it can randomly extract `raw data X` for double-checking and entrust it to validator `B`, `C` and `D` (sending back the request to them in the FB). +**Example**: `raw data X` came from `user A`, resulting in `hash Y` from `validator A`. Randomly, the Parachain extracts some computational problems to be double-checked. For example, it can randomly extract `raw data X` for double-checking and entrust it to validator `B`, `C` and `D` (sending back the request to them in the FB). `B`, `C` and `D` compute `X` again. Presuming that the majority of `B`, `C` and `D` (so at least two of them) are honest, the majority of them should compute `X` and obtain the same hash (`hash Z`). They send the hash back to the Parachain, and than compare the hashes. If for at least two validators (between `B`, `C` and `D`) `hash Z` = `hash Y` (the same hash obtained by `validator A`), `validator A` is then presumed honest and can continue with its validating activity. If, instead, for at least 2 validators (between `B`, `C` and `D`) `hash Z` ≠ `hash Y`, `validator A` is presumed a liar. -Since to be a validator `A` needed both to provide GPU and/or CPU processing capacity and to buy and stake DataGen native tokens, is easy to impose an economical cost for the cheating `validator A` by making it loose staked coins as a consequence of its wrong computation. In this regard the Parachain acts as an authority for the random processes of the FB. +Since to be a validator `A` needed both to provide GPU and/or CPU processing capacity and to buy and stake DataGen native tokens, is easy to impose an economical cost for the cheating `validator A` by making it loose staked coins as a consequence of its wrong computation. In this regard the Parachain acts as an authority for the random processes of the FB. We prefer the use of a Parachain, instead of two FB or a HB of our own FB, because of the improved resiliency that the Polkadot ecosystem can provide. -We must underline that, even if the goal of this very complex design is to keep even the hardware layer as decentralized as possible (compared to a PoS network, where there is strong economic incentive for a validator to host the computing capacity on the top of centralized server farm like AWS) we can’t prevent the validators hosted on centralized providers to participate to the network. +We must underline that, even if the goal of this very complex design is to keep even the hardware layer as decentralized as possible (compared to a PoS network, where there is strong economic incentive for a validator to host the computing capacity on the top of centralized server farm like AWS) we can’t prevent the validators hosted on centralized providers to participate to the network. The trade-off for such a result would so impede efficiency and low latency that, instead of trying to attain it (for some ideological reason of decentralization per self) we think we should try keeping the hardware layer of the network _decentralized enough_. We think that this can be attained as a collateral result of the above explained ECHO procedure (whose primary goal is to increase the overall efficiency and decrease the overall latency time of the network, by pairing users and validators on the basis of response time). -This collateral positive externality happens since validators that are faster to respond to specific clusters of users are rewarded by the process with the right to provide the cloud computing power requested by those clusters, with meaningful consequences for the geographical distribution of the validators themselves: in some geographical contexts (US coasts or Western Europe), where the internet connection is fast and big server farms are close-by, this will keep the economic incentive for validators to be hosted in centralized server farms; on the opposite, in other contexts (like some parts of South-East Asia, Sub-Saharan Africa and LATAM), where broadband connection is slow or inexistent and server farms far away, there will be a strong economic incentive to set up independent hardware facilities to validate the activity of local or regional areas. +This collateral positive externality happens since validators that are faster to respond to specific clusters of users are rewarded by the process with the right to provide the cloud computing power requested by those clusters, with meaningful consequences for the geographical distribution of the validators themselves: in some geographical contexts (US coasts or Western Europe), where the internet connection is fast and big server farms are close-by, this will keep the economic incentive for validators to be hosted in centralized server farms; on the opposite, in other contexts (like some parts of South-East Asia, Sub-Saharan Africa and LATAM), where broadband connection is slow or inexistent and server farms far away, there will be a strong economic incentive to set up independent hardware facilities to validate the activity of local or regional areas. Those independent validators, while not optimally located to compete with AWS-hosted validators for users in the “north of the world”, can also become validators of last resort in the case in which the centralized server farms are not providing service anymore (it can be due to technical outage or political pressure for censorship or other factors). As said, the goal is not to expel AWS-hosted validators from the Datagen network, but to keep it decentralized enough while being at the same time low latency and computationally efficient. @@ -62,7 +61,8 @@ The only computational activity that is happening off-chain is (following the ex Ideally, we would like to explore some technic to keep light the blockchains long-term to keep it clean of old unnecessary raw data and just having hashes long term (that’s why we like so much Polkadot’s feature that allows blockchains to evolve without forking). -So Datagen is **NOT**: +So Datagen is **NOT**: + - providing cloud storage of processed data; - doing substantial stuff off-chain; - PoW; @@ -82,7 +82,7 @@ For the above explained reasons, we see Phala more like a complementary project In other ecosystems we can see different competitors, each one with a very different both technical and go to market approach (explaining them one to one will be too long to explain in this grant application), both off-chain and in-chain. -Off-chain SONM (independent copy-cat of the Ethereum blockchain), Aleph.im (Solana, cross-chain compatible). And (more or less) in-chain: Akash (Solana Nodes + Cosmos), Golem (Ethereum), Cudos (L1, independent, cross-chain compatible), StackOS (Binance Polygon, Avalanche) and others. +Off-chain SONM (independent copy-cat of the Ethereum blockchain), Aleph.im (Solana, cross-chain compatible). And (more or less) in-chain: Akash (Solana Nodes + Cosmos), Golem (Ethereum), Cudos (L1, independent, cross-chain compatible), StackOS (Binance Polygon, Avalanche) and others. The existence of many competitors (each different from the other) in many different stacks is for us a confirmation that we are working on something that matters and we think that for the Polkadot ecosystem is important to harbor different cloud computing projects, with different (in some points complementary and in other alternative) approaches, both to help boosting the wider Web3 environment to shift away from centralized Web2 providers like AWS, Google Cloud, Azure, IBM, Alibaba and to acquire and retain valuable projects while competing with other major stacks, because cloud computing matters a lot in the web economy and in the web physical infrastructure and for a top stack like Polkadot / Kusama should matter _where_ cloud computing, as a strategic asset, is happening. @@ -115,19 +115,19 @@ In particular is possible to observe that the Solana ecosystem is backing both o ### Team's experience -Both founders (Angela & Luca) have a legal background. They entered in the blockchain space in 2019 (shifting carrier) because they both strongly believe in the transformative power that the blockchain revolution can have on society. +Both founders (Angela & Luca) have a legal background. They entered in the blockchain space in 2019 (shifting carrier) because they both strongly believe in the transformative power that the blockchain revolution can have on society. -After ≈1 year of self-taught study of the blockchain technology and market, they incorporated B-Datagray in late 2020. At the beginning it was a very lonely but enriching journey, since they had 0 previous connection in the industry, 0 track record and 0 capital. Angela and Luca started being full-time on the project in January 2021. +After ≈1 year of self-taught study of the blockchain technology and market, they incorporated B-Datagray in late 2020. At the beginning it was a very lonely but enriching journey, since they had 0 previous connection in the industry, 0 track record and 0 capital. Angela and Luca started being full-time on the project in January 2021. -In Spring 2021 they started building the technical team (at the beginning all part time, due to the lack of capital) and not without encountering not particularly honest devs, while that made things more difficult short-term, long-term it allowed the funders to become more skilled in managing a team. Our currently beautiful team started to come togheter after summer 2021. +In Spring 2021 they started building the technical team (at the beginning all part time, due to the lack of capital) and not without encountering not particularly honest devs, while that made things more difficult short-term, long-term it allowed the funders to become more skilled in managing a team. Our currently beautiful team started to come togheter after summer 2021. -In that period, we also entered in the XEurope Accelerator. Ren (with 7 years of coding experience and 5 of Solidity coding) was the first to become mostly full-time, in October 2021, before we were able to pay him a salary. +In that period, we also entered in the XEurope Accelerator. Ren (with 7 years of coding experience and 5 of Solidity coding) was the first to become mostly full-time, in October 2021, before we were able to pay him a salary. In November B-Datagray received the first VC investment and to date we have 2 VC and 2 angel investments. We have developed all the tokenomic smart contracts, including a community governance smart contract to help smoothing the transition from the BSC to our Native + Polkadot blockchain and all of them have been audited by Certik. B-Datagray has also been recently finalist at the MIT Bitcoin Pitch Competition 2022. -We know that we still have much to grow and to learn, but all the journey until here and now taught to B-Datagray’s founder a great deal about bootstrapping and managing a company and about doing much with very little. +We know that we still have much to grow and to learn, but all the journey until here and now taught to B-Datagray’s founder a great deal about bootstrapping and managing a company and about doing much with very little. -The ability and willingness to learn and grow and change and to work hard and to believe, even in the most difficult moment, and to find the resources, in the inner-self and in the other people, even when is seemingly and rationally impossible, in our opinion is more important than any learned skill for team and project leaders, since is an attitude that you have inside you and that you express in every aspect of your personal and professional life and that will be determinant to solve any of the multiple problems that will inevitably and unexpectedly occur during the project’s lifetime. +The ability and willingness to learn and grow and change and to work hard and to believe, even in the most difficult moment, and to find the resources, in the inner-self and in the other people, even when is seemingly and rationally impossible, in our opinion is more important than any learned skill for team and project leaders, since is an attitude that you have inside you and that you express in every aspect of your personal and professional life and that will be determinant to solve any of the multiple problems that will inevitably and unexpectedly occur during the project’s lifetime. All our devs (and our designers) are professionals and also very committed to learning and improving constantly their skills. @@ -156,7 +156,7 @@ All our devs (and our designers) are professionals and also very committed to le ## Development Status -What we have already developed (using Solidity) is all the tokenomic smart contracts regulating our DataGen token (#DG), including one to smooth the transition from the BSC network to the Polkadot / Native Datagen Infrastructure, with a rigorously decentralized community voting procedure (https://github.com/Datagen-Project/DataGen-Smart-Contracts/blob/main/contracts/MiningReservation.sol). +What we have already developed (using Solidity) is all the tokenomic smart contracts regulating our DataGen token (#DG), including one to smooth the transition from the BSC network to the Polkadot / Native Datagen Infrastructure, with a rigorously decentralized community voting procedure (https://github.com/Datagen-Project/DataGen-Smart-Contracts/blob/main/contracts/MiningReservation.sol). In total our team has already developed around ≈2K lines of code of smart contracts just for the Datagen project, excluding of course the default configurations (like lock.json , etc…), we are speaking of functional code. In addition to that, we have in private repo the functional code for the website and the sale interface. @@ -189,11 +189,11 @@ The goal is to achive a fully functional mechanism for the random selection of t | 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** on Medium that explains how we are going to develop the pallet. | | 1. | Substrate pallet | We will create a `pallet_random_node_selector` that implement the randomized selection of the nodes for the fast blockchain using the Substrate `Randomness` trait. This pallet run on the Heavy Blockchain. | -|1a.| Functions |
  • `reliable_node` update the list of the reliable nodes on the Heavy Blockchain.
  • `random_checker_node_selector` select 3 reliable random nodes in the fast blockchain to check the computational work.
  • `random_node_to_check` select a single random node to be check by the 3 checker nodes.
+|1a.| Functions |
  • `reliable_node` update the list of the reliable nodes on the Heavy Blockchain.
  • `random_checker_node_selector` select 3 reliable random nodes in the fast blockchain to check the computational work.
  • `random_node_to_check` select a single random node to be check by the 3 checker nodes.
|2.| Substrate pallet | We will create a `pallet_computational_work` that runs computational work on the fast nodes and pair them with their works. |2a.| Functions |
  • `math_work_testing` this function will provide math problems to solve by Fast Blockahin nodes, just for testing.
  • `hash_work` function will hash the raw math problem and the elaborated result from the node and pair, comunicate to the Heavy Blockchain.
|3.| Substrate pallet| We will crate a `pallet_check_node_computational_work` that manage the control process on the Fast Blockchain. -|3a.| Functions |
  • `check_computational_work` take info from the Heavy Blockchain (from the `pallet_random_node_selector`) and check the computational work of the target node. At this moment the nodes will make a simple math calculations just to check the mechanism.
  • `check_result` elaborate the result of the check process. If checked node has the same result of the majority of the checker nodes nothing happen. If the majority of the nodes have a different result from checked node this one will lose all his staked tokens (at this moment we only simulate the token lost) and checked node will be excluded from the Fast Blockchain.
  • `reliable_node` update the list of the reliable nodes on the Fast Blockchain.
+|3a.| Functions |
  • `check_computational_work` take info from the Heavy Blockchain (from the `pallet_random_node_selector`) and check the computational work of the target node. At this moment the nodes will make a simple math calculations just to check the mechanism.
  • `check_result` elaborate the result of the check process. If checked node has the same result of the majority of the checker nodes nothing happen. If the majority of the nodes have a different result from checked node this one will lose all his staked tokens (at this moment we only simulate the token lost) and checked node will be excluded from the Fast Blockchain.
  • `reliable_node` update the list of the reliable nodes on the Fast Blockchain.
### Milestone 2 — Connecting the two blockchains @@ -231,10 +231,10 @@ The goal is to achive a fully functional mechanism for the random selection of t | 1. | Web Dapp | We will create a web dapp to verify the functionality of the infrastructure, the GUI will display interactions between the two blockchains. | | 1a.| Dapp Mock-up| Download the mock-up of the dapp at [this link](https://drive.google.com/drive/folders/1SJRPbczZhRaXVLHnLvmp_XIeBtBBv0g-). | | 1b. | Home page | ![home page](https://i.imgur.com/MhQVfEj.png)
  1. Filter to switch between the two blockcahins for searching purpose
  2. Searching field (could search for blocks or nodes by typing id)
  3. The id of the last node checked with `check_computational_work` pallet
  4. The total number of nodes checked with `check_computational_work` pallet
  5. Total checks with `check_computational_work`
  6. Avarage number of checks on a single fast node with `check_computational_work` pallet
  7. Id of a fast blockchain node
  8. Number of checks on a node with `check_computational_work` pallet
  9. The fast nodes that verify the computational work with `check_computational_work` pallet
  10. Check result from `check_computational_work` pallet
  11. Total blocks finalized by the blockcahin
  12. Total nodes of the blockchain
  13. Block height
  14. Block age
  15. Validator id of the block
| -| 1c. | Fast Blockchain - Block Page| ![FB Block](https://i.imgur.com/ZDMuX7I.png)
  1. Blockchain identifier
  2. Block identifier (height)
  3. Block height, arrows change the block by 1 (left -1, right +1)
  4. The age of the block and its creation time
  5. Validator identifier, optionally a name and time required to validate the block
  6. Total number of fast nodes at this block height
  7. Number of nodes checked with `check_computational_work` pallet in this block
      8. | +| 1c. | Fast Blockchain - Block Page| ![FB Block](https://i.imgur.com/ZDMuX7I.png)
      1. Blockchain identifier
      2. Block identifier (height)
      3. Block height, arrows change the block by 1 (left -1, right +1)
      4. The age of the block and its creation time
      5. Validator identifier, optionally a name and time required to validate the block
      6. Total number of fast nodes at this block height
      7. Number of nodes checked with `check_computational_work` pallet in this block
      | | 1d. | Heavy Blockchain - Block Page | ![HB Block](https://i.imgur.com/iJCc6nh.png) For functionalities see 1c. list. | -| 1e. | Fast Blockchain - Node Page | ![FB Node](https://i.imgur.com/wOBlIdp.png)
      1. Node identifier
      2. Node identifier arrows change the node by 1 (left -1, right +1)
      3. Blockchain identifier
      4. Last time node checked with `check_computational_work` pallet.
      5. Total number of checks with `check_computational_work` pallet on this node
      6. How many pass results on this block
          7. | -| 1f. | Heavy Blockchain - Node Page | ![HB Node](https://i.imgur.com/IYEyVzA.png) For functionalities see 1e. list.| +| 1e. | Fast Blockchain - Node Page | ![FB Node](https://i.imgur.com/wOBlIdp.png)
          1. Node identifier
          2. Node identifier arrows change the node by 1 (left -1, right +1)
          3. Blockchain identifier
          4. Last time node checked with `check_computational_work` pallet.
          5. Total number of checks with `check_computational_work` pallet on this node
          6. How many pass results on this block
          | +| 1f. | Heavy Blockchain - Node Page | ![HB Node](https://i.imgur.com/IYEyVzA.png) For functionalities see 1e. list.| ## Future Plans diff --git a/applications/DipoleOracle.md b/applications/DipoleOracle.md index c94d3c19bf5..3159a93cfb1 100644 --- a/applications/DipoleOracle.md +++ b/applications/DipoleOracle.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Dipole Oracle -* **Project:** Dipole Oracle * **Proposer:** [KK](https://www.linkedin.com/in/kaikai-yang) diff --git a/applications/DistributedKeyManagement.md b/applications/DistributedKeyManagement.md index dbbb9128c8d..4697bed24bb 100644 --- a/applications/DistributedKeyManagement.md +++ b/applications/DistributedKeyManagement.md @@ -1,109 +1,104 @@ # Distributed Key Management - - + - **Team Name:** Jett Hays (Individual) - **Payment Address:** 0x33644e4D6bb589854fbb906276147Afd7de86E09 (ERC-20 USDC) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 - - + ## Project Overview :page_facing_up: - - + ### Overview - - + This project will explore the security and applications of using secret sharing to distribute wallet ownership. - -Public key cryptography has enabled encrypted communication and global computing protocols like Polkadot. -But managing keys is hard. Existing noncustodial key management solutions require memorizing long mnemonic phrases, using network specific smart contracts, -or purchasing complicated hardware wallets. These solutions are insufficient for the majority of users who are looking for a simple way to manage private keys. -This grant will support research on a distributed key management system and an open source reference implementation. + +Public key cryptography has enabled encrypted communication and global computing protocols like Polkadot. +But managing keys is hard. Existing noncustodial key management solutions require memorizing long mnemonic phrases, using network specific smart contracts, +or purchasing complicated hardware wallets. These solutions are insufficient for the majority of users who are looking for a simple way to manage private keys. +This grant will support research on a distributed key management system and an open source reference implementation. If successful, this project will help make Polkadot hot wallets more secure and simplify online ownership. With the proposed system, wallets could implement 2fa and authenticate with their existing Google or Apple account. - + I believe wallets are the connection point between users and the decentralized web. Making this connection point accessible and secure is incredibly exciting and drives my interest in developing this project. - + ### Project Details - + This is a research project focused on distributed key management. The basic idea involves sharing a secret– in this case, a BIP32 seed phrase– between a client and remote servers. When the private key is needed, the shares are reassembled on the client and used within a standard key manager. The local key manager can then be used to publish transactions, encrypt data, validate identity, etc. I have already implemented a version of this idea within the open source Kryptik wallet. However, more research is required to answer essential security questions (discussed in the project timeline) and provide a common reference implementation. A skeleton of the distributed key management system, as implemented by the Kryptik wallet, is described below. - + ##### Client Seedloop - + Wallets are derived from a single parent key. This parent key is used as a seed to generate a child key for each blockchain network, in accordance with the BIP 32 specification for hierarchical deterministic wallets. Child keys may produce an array of addresses and have custom methods depending on the network type. This cluster of keyrings is stored on a single seed loop object that contains the parent key. The seedloop can be encrypted with a standard password by the user at any point in time. - + ##### Local Storage - -When a wallet is created, the wallet object is serialized, encrypted, and stored in the browser’s local storage. The random encryption secret is then split with shamir secret sharing into two shares. One share is held locally and one share is sent to the database. When a new user session begins, the service retrieves the database share and combines it locally into the original encryption secret. The wallet can then be decrypted, deserialized, and made available for use. This arrangement results in a two-of-two security scheme, where an attacker must compromise both systems to obtain a user’s private seed. - + +When a wallet is created, the wallet object is serialized, encrypted, and stored in the browser’s local storage. The random encryption secret is then split with shamir secret sharing into two shares. One share is held locally and one share is sent to the database. When a new user session begins, the service retrieves the database share and combines it locally into the original encryption secret. The wallet can then be decrypted, deserialized, and made available for use. This arrangement results in a two-of-two security scheme, where an attacker must compromise both systems to obtain a user’s private seed. + ##### Authentication -Kryptik uses a decentralized authentication provider to generate a user identifier which is passed to the user through a ‘magic’ link sent via email. The ID is then exchanged with the database for an access token and the user session begins. - + +Kryptik uses a decentralized authentication provider to generate a user identifier which is passed to the user through a ‘magic’ link sent via email. The ID is then exchanged with the database for an access token and the user session begins. + ##### Conclusion -This system has worked well during public testing. However, improvements must be made to generalize beyond a 2 of 2 system– this has potential implications for social recovery– and research must be conducted to understand the security implications of distributed key management as described above. This project will accomplish both of these goals in addition to providing a common reference implementation. - - + +This system has worked well during public testing. However, improvements must be made to generalize beyond a 2 of 2 system– this has potential implications for social recovery– and research must be conducted to understand the security implications of distributed key management as described above. This project will accomplish both of these goals in addition to providing a common reference implementation. + ### Ecosystem Fit - + Secure and usable key management is an open issue. This project will improve the security of hot wallets– through encryption, 2fa, and distributed secret sharing– and provide users with a simple key management flow: just authenticate like you would for any other app! - + The initial research will be used to improve the distributed key management implementation currently used by the Kryptik wallet. However, the research, code, and documentation are designed for the broader developer community to use in their own app that supports Polkadat or Kusama. - + ## Team :busts_in_silhouette: - + ### Team members - + Leader: Jett Hays Advisor: Nicolas Christin - + ### Contact - + - **Contact Name:** Jett Hays - **Contact Email:** jehays@andrew.cmu.edu - **Website:** [jetthays.com](https://jetthays.com/) - + ### Legal Structure - + Individual / Sole Proprietor - + ### Team's experience - -Jett Hays is the President of the Carnegie Mellon blockchain club where he helps members build and understand the decentralized future. Previous projects have included a open source key management package[https://github.com/KryptikApp/kryptik-seedloop] and a (multichain web wallet)[https://www.kryptik.app/]. Both projects have received support from Carnegie Mellon and multiple blockchain foundations. - - + +Jett Hays is the President of the Carnegie Mellon blockchain club where he helps members build and understand the decentralized future. Previous projects have included a open source key management package[https://github.com/KryptikApp/kryptik-seedloop] and a [multichain web wallet](https://www.kryptik.app/). Both projects have received support from Carnegie Mellon and multiple blockchain foundations. + ### Team Code Repos - -- https://github.com/KryptikApp -- https://github.com/KryptikApp/kryptikwebapp -- https://github.com/KryptikApp/kryptik-seedloop - -- https://github.com/jettblu - + +- +- +- + +- + ### Team LinkedIn Profiles (if available) - -- https://www.linkedin.com/in/jett-hays-491b541b7/ - + +- + ## Development Status :open_book: - + The idea of a distributed key manager came to me during a class at Carnegie Mellon on shamir secret sharing. After coming up with a rough interface, I applied for a small undergraduate research grant from CMU, with Professor Nicolas Christin agreeing to be my advisor. This research led me to create the open source Kryptik wallet, whcih I have been working on for the past year. A short demo of the wallet can be found via [this link](https://vimeo.com/745609041). This wallet uses a simple version of the distributed key management system I described above. - + As part of this project, I also released a seedloop manager as an open source NPM package, which can be found [here](https://github.com/KryptikApp/kryptik-seedloop). This package allows developers to easily generate wallets and sign transactions across multiple blockchains. - + ## Development Roadmap :nut_and_bolt: - - + ### Overview - + - **Total Estimated Duration:** 3 months - **Full-Time Equivalent (FTE):** .4 FTE - **Total Costs:** $8,000 - + ### Milestone 1 - Research Paper - + - **Estimated duration:** 10 weeks - **FTE:** 0.4 FTE - **Costs:** 5,000 USD - + | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | @@ -113,15 +108,13 @@ As part of this project, I also released a seedloop manager as an open source NP | 0e. | Article | We will publish an article that summarizes the key findings of our distributed key management research for developers (who may not be interested in the nitty gritty technical details or security models). | | 1. | Formal Investigation | The research period will be spent investigating the following questions about the kryptik key management system. What is the threat model? How can keys be synced across devices? How can the system include more than two shareholders? What is the ideal number of shareholders? Is there any application to social recovery? By the end of this period, I will have organized a sequence of proofs and thoughts that can be shaped into a paper. Each question and associated discovery will be documented via regular blog posts.| | 2. | Research Paper | This paper will include an in depth analysis of the research questions discussed above. Professor Nicolas Cristin of Carnegie Mellon will help advise the paper– he served as an advisor for my initial research grant from CMU. The paper will be released as an open source document on Github. We expect this open source key management knowledge to provide a strong foundation for future Polkadot/Kusama/Substrate wallet designers.| - - - + ### Milestone 2 — Reference Implementation - + - **Estimated Duration:** 1 month - **FTE:** .4 - **Costs:** 3,000 USD - + | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | @@ -134,23 +127,18 @@ As part of this project, I also released a seedloop manager as an open source NP | 3. | Share Module | The share module will generate shamir shares for a given piece of data (in this case the encryption secret). This module will also allow shares to be recombined (according to the k of n secret sharing scheme) to reconstruct the original piece of data. | | 4. | Sync Module | This module will allow seed vaults to be synced across devices.| | 5. | Web Deployment | And finally, we will wrap these modules in a nice UI and deploy the interface to a website (likely using NextJs + Vercel). This website will allow developers to create a vault, sync their devices, and sign sample transactions. This will be accomplished via open source React components that developers can reuse in their own application. The deployed app will have Polkadot/Kusama/Substrate specific examples (address generation, signatures, etc) that will benefit future developers.| - - - + ## Future Plans - + After the grant is completed, I will continue improving the open source Kryptik wallet, which builds upon the distributed key management system described above. Work on the wallet interface– which has been sponsored by other grants– will necessarily include revisiting the key management system and making improvements (such as adding the ability to sync key shares between devices). Beyond that, the research and published paper are a timeless body of knowledge that will continually benefit production implementations and new research on key management. - - + ## Additional Information :heavy_plus_sign: - + **How did you hear about the Grants Program?** I first heard about the grants program at EthDenver 2022. I then learned more about the program via the Web3 Foundation Website. - + The NEAR foundation awarded a $45,000 grant to develop the Kryptik wallet interface. This work wrapped the key management system with software that supports multi chain swaps, collectibles, payments, etc. I also received $20,000 from the Solana Foundation to provide open source documentation and Solana specific examples. Both of these grants are directed towards the Kryptik wallet interface, not the key management system which was devised separately. - + Finally, I received $500 from Carnegie Mellon to build the key manager and host the wallet interface. **How does this project benefit the Polkadot/Kusama/Substrate ecosystem? -Asymmetric key management is an open issue that affects every blockchain ecosystem. An improved key management system will help improve wallet design which, in turn, will help improve the user experience of the Polkadot/Kusama/Substrate ecosystem. The research proposed above will provide foundational knowledge and software that can be integrated into existing Polkadot related wallets and in emerging wallets that have yet to be designed. In summary, successful execution of the grant will result in a simple and more secure way to interact with the Polkadot/Kusama/Substrate ecosystem. This will benefit users, who will have an improved wallet experience, and developers who can build upon a novel approach to key management. - - +Asymmetric key management is an open issue that affects every blockchain ecosystem. An improved key management system will help improve wallet design which, in turn, will help improve the user experience of the Polkadot/Kusama/Substrate ecosystem. The research proposed above will provide foundational knowledge and software that can be integrated into existing Polkadot related wallets and in emerging wallets that have yet to be designed. In summary, successful execution of the grant will result in a simple and more secure way to interact with the Polkadot/Kusama/Substrate ecosystem. This will benefit users, who will have an improved wallet experience, and developers who can build upon a novel approach to key management. diff --git a/applications/DotPay.md b/applications/DotPay.md index 1bd7a29e9b4..1a6f2a20ab4 100644 --- a/applications/DotPay.md +++ b/applications/DotPay.md @@ -1,6 +1,5 @@ # DOT PAY -- **Project Name:** DOT PAY - **Team Name:** Crypto Pay Lab (CPL) - **Payment Address:** 3CnxDH6myTaK6MVy3SawVF2FC6FdgfK8pj （BTC address） - **[Level]:** 2 @@ -9,19 +8,18 @@ #### Why Dotpay -Many developers love open source very much, but they have no way to devote themselves to the construction of open source, +Many developers love open source very much, but they have no way to devote themselves to the construction of open source, because they can't get enough compensation for users' lives in the process of contributing to open source projects, so they must be employed by a certain company. -We hope to use the power of blockchain to change this status quo. +We hope to use the power of blockchain to change this status quo. -The owner of an open source project can initiate paid tasks, and developers can complete tasks to get paid. +The owner of an open source project can initiate paid tasks, and developers can complete tasks to get paid. -Note that it is not a tip. This will allow more power to participate in open source projects and make open source projects better. +Note that it is not a tip. This will allow more power to participate in open source projects and make open source projects better. The development of the company generates greater value, and then more funds can be used to pay developers to form a virtuous circle. - #### What is Dotpay DotPay is a platform that supports paid tasks to complete open source projects on Github. @@ -42,13 +40,13 @@ Page 2: Configure Github webhook Page 3: Recharge ![image](https://user-images.githubusercontent.com/94216827/142724518-a22d1760-eeb8-4399-b0ac-e04348002beb.png) -Page 4: Creat tasks and trigger the payment +Page 4: Creat tasks and trigger the payment ![image](https://user-images.githubusercontent.com/94216827/142757369-7bb816ae-b834-4a80-a562-8bb21da0624f.png) Page 5: Bind reward address -If the developer has not bound the address before, -the system will prompt him to use the following instructions to bind, +If the developer has not bound the address before, +the system will prompt him to use the following instructions to bind, just reply to similar instructions like `/dotpay bind [address]` in the issue corresponding to the task ![image](https://user-images.githubusercontent.com/94216827/145700577-bb02ef26-cebd-4516-bc9b-772a90f36b68.png) @@ -60,6 +58,7 @@ just reply to similar instructions like `/dotpay bind [address]` in the issue co DotPay is a payment platform, you can initiate open source tasks and paid with DOT tokens (for example, you can initiate paid collaboration tasks when you encounter difficulties in architecture construction, requirements analysis, document construction and testing). Those who complete the tasks as required can receive tokens after the task initiator verifies that the tasks are completed The specific process is as follows: + 1. Alice recharge Dot tokens on the platform. 2. Alice initiates paid open source tasks on the Github (such as the task about architecture construction, requirements analysis, document construction, development and testing, etc ) 3. Bob accepted this task on Github and completed it! @@ -112,16 +111,16 @@ Command line in issue reply: `/pay Bob 10DOT` ### An overview of the technology stack to be used -* Font-end, typescipt,react -* Backend, golang,Rust -* Devops, github action, kubenretes -* Search, MeiliSearch +- Font-end, typescipt,react +- Backend, golang,Rust +- Devops, github action, kubenretes +- Search, MeiliSearch ### Key Functions 0. User management - - Using github OAuth2 login, user group management. - + - Using github OAuth2 login, user group management. + 1. Email / Issue informal - Imformal user to withdraw their DOT tokens. @@ -138,40 +137,39 @@ Command line in issue reply: `/pay Bob 10DOT` 5. Issue search - Users can find and filter paid collaboration tasks that meet their requirements in the issue search form. -6. Payment secrect management +6. Payment secrect management - Create it on DotPay website and config it to github secrect to pay user DOT. - + 7. Recharge & transfer by ink! contract -* Set the maximum amount and maximum total amount for each transaction +- Set the maximum amount and maximum total amount for each transaction set_limit(per_transfer_amount, total_transfer_amount) Only the owner of the project has the calling permission -* Set up the transfer whitelist +- Set up the transfer whitelist set_witelist(username, address) Only the owner of the project has the calling permission -* Transfer interface +- Transfer interface transfer(address,amount) The platform has the calling permission Benefits of this design: -* The platform no longer needs the owner to recharge, just need to sign a contract with the owner -* The platform does not have the authority to set a whitelist, ensuring that the platform cannot transfer funds to addresses other than the whitelist set by the owner -* The single maximum amount and the total amount set to a certain extent ensure the safety of the owner's funds - +- The platform no longer needs the owner to recharge, just need to sign a contract with the owner +- The platform does not have the authority to set a whitelist, ensuring that the platform cannot transfer funds to addresses other than the whitelist set by the owner +- The single maximum amount and the total amount set to a certain extent ensure the safety of the owner's funds ### Ecosystem Fit -As far as I am concerned, there are no similar projects in Polkadot ecosystem. +As far as I am concerned, there are no similar projects in Polkadot ecosystem. Maybe we have some similarities with dotmarket, there are still many differences to compare with dotmarket, dotpay will focus on open-source payment collaboration, deep integration with GitHub, closer to end-users， -what's more important is we prefer to realize open source payment cooperation in Polkadot ecosystem. +what's more important is we prefer to realize open source payment cooperation in Polkadot ecosystem. -As we all know Polkadot offers flexible cross-chain interoperation functionality with a large user base and volume expectation, +As we all know Polkadot offers flexible cross-chain interoperation functionality with a large user base and volume expectation, and as a mainstream cryptocurrency with high market value, DOT tokens is easier for developers to accept and be recognized， @@ -181,56 +179,55 @@ And we also look forward to cooperating with dotmarket in the future. ## Team :busts_in_silhouette: -### Team members +### Team members We will pleased to offer github accounts, LinkedIn and any other information in private. All team members can contact privately for any specific information. -* Richard Fang: team leader, core developer +- Richard Fang: team leader, core developer -* Fugen Wang: Background development +- Fugen Wang: Background development - responsible for the development of the website background. -* Yang Li: +- Yang Li: - Responsible for front-end development. -* Peng Qiao: Rust developer +- Peng Qiao: Rust developer - Responsible for back-end development, relevant development of blockchain, payment task management module, and docking API and key management module on the chain. - -* Wei Zhang: +- Wei Zhang: - Responsible for operation, promotion in the open source community after the website is launched, and attracting open source projects to use our services. - -* AdaLam: PD/PMO + +- AdaLam: PD/PMO - Responsible for product design and project schedule management. - + ### Team's Experience -* Richard Fang: - - As an expert in the field of cloud computing in one of the biggested Internet listed companies with 7 years of rich working experience. - - The author of a well-known cloud native project which has more than 5K stars and 4k paid enterprise users. +- Richard Fang: + - As an expert in the field of cloud computing in one of the biggested Internet listed companies with 7 years of rich working experience. + - The author of a well-known cloud native project which has more than 5K stars and 4k paid enterprise users. -* Fugen Wang: - - CEO of an Internet start-up company and manages more than a dozen employees with 7 years working experience. +- Fugen Wang: + - CEO of an Internet start-up company and manages more than a dozen employees with 7 years working experience. -* Yang Li: - - Andriod/IOS front-end engineer with 5 years working experience. - -* Peng Qiao: - - A core member of AI Research Institute wich is one of the top AI listed companies in China with 5 years working experience. - -* Wei Zhang: - - An advertising director, one of the top AI listed companies in China with 7 years of rich working experience. - -* AdaLam: PD/PMO +- Yang Li: + - Andriod/IOS front-end engineer with 5 years working experience. + +- Peng Qiao: + - A core member of AI Research Institute wich is one of the top AI listed companies in China with 5 years working experience. + +- Wei Zhang: + - An advertising director, one of the top AI listed companies in China with 7 years of rich working experience. + +- AdaLam: PD/PMO - Familiar with product design and project schedule management. ### Contact - **Contact Name:** AdaLam - **Contact Email:** adalamlzy@gmail.com -- **Website:** comming soon +- **Website:** comming soon - **Contact Name:** Richard Fang - **Contact Email:** lamelegdog@gmail.com @@ -241,9 +238,9 @@ We will be pleased to offer specific information in private. ### Team Code Repos -https://github.com/bytepayment + -https://github.com/bytepayment/bytepay + ### Team LinkedIn Profiles @@ -253,14 +250,15 @@ We will provid in private through Google Form. ### Overview -* **Total Estimated Duration:** 8 weeks -* **Full-time equivalent (FTE):** 5 -* **Total Costs:** 30,000 USD +- **Total Estimated Duration:** 8 weeks +- **Full-time equivalent (FTE):** 5 +- **Total Costs:** 30,000 USD ### Milestone 1 — User account management & repo management & mnemonic management + * **Estimated Duration:** 4 weeks -* **FTE:** 5 -* **Costs:** 15,000 USD +- **FTE:** 5 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -275,9 +273,10 @@ We will provid in private through Google Form. | 5. | Transfer ink! contract| We will provide an tested ink! contract on Substrate Smart Contracts Node, provide transfer limit, witelist and transfer function. The platform will integrate the contract when the Polkadot mainnet contract para chain is available. | ### Milestone 2 — Transfer module, task module, informal, withdraw module + * **Estimated Duration:** 4 weeks -* **FTE:** 5 -* **Costs:** 15,000 USD +- **FTE:** 5 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -290,11 +289,9 @@ We will provid in private through Google Form. | 3. | Withdraw module | Withdraw the DOT from our platform to developer own wallet, if developer bind it own address, payment will transfer to the account directly | | 4. | Informal | Developer will receive the event, tell him how to withdraw DOT in our platform, robot will send Bob email and comment the issue | - - ## Development Status -https://github.com/bytepayment/bytepay + We have developed the webhook event processing module. The following is a brief description of what the repository contains: @@ -302,17 +299,17 @@ Including GitHub webhook server，it can listen to GitHub events, handle some sp ## Future Plans -- About our future plan, we will support more payment scenarios, such as website recharge VIP and online payment to buy goods after completing this grant. -- And then, we are going to support more platforms to expand the number of users, not only completing paid tasks on Github , but also on Telegram, Discord, Twitter, etc, +- About our future plan, we will support more payment scenarios, such as website recharge VIP and online payment to buy goods after completing this grant. +- And then, we are going to support more platforms to expand the number of users, not only completing paid tasks on Github , but also on Telegram, Discord, Twitter, etc, and we also have an idea that cross-chain cooperation with other project. -- After that, We will launch our own Polkadot para-chain tokens and the open source developers will receive tokens by completing the paid tasks on Github. +- After that, We will launch our own Polkadot para-chain tokens and the open source developers will receive tokens by completing the paid tasks on Github. ## FAQ -> Why not use Paypal? +> Why not use Paypal? -Paypal has obvious borders for global developer collaboration, and it is not convenient to use. +Paypal has obvious borders for global developer collaboration, and it is not convenient to use. -In fact, we did similar attempts at the earliest and found that many countries do not use Paypal at all. +In fact, we did similar attempts at the earliest and found that many countries do not use Paypal at all. And we hope that open source paid collaboration More decentralized rather than relying on a certain company. diff --git a/applications/DotPulse.md b/applications/DotPulse.md index 8e88c06fd9f..56950c47ae7 100644 --- a/applications/DotPulse.md +++ b/applications/DotPulse.md @@ -1,6 +1,5 @@ -# W3F Open Grant Proposal +# DotPulse -- **Project Name:** DotPulse - **Team Name:** CrossChain Labs - **Payment Address:** 0xC289B81a8e5f8F8d691b4Cf1DBc16A7107B630e3 (USDC) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 @@ -16,6 +15,7 @@ The solution that CrossChain Labs presents is going to address the problems desc ### Project Details Deliverables: + - GitHub Scraper that will collect all the required data from GitHub - DotPulse APIs that will serve to get the data from the scraper and interact with the DotPulse dashboard - DotPulse Dashboard that will include: @@ -28,33 +28,34 @@ Deliverables: Dashboard Overview -DotPulse +DotPulse ### Ecosystem Fit The DotPulse project will enable all the interested parties to track the development among different Polkadot organisations on Github, to follow the number of commits, repositories, contributors, PRs, the top contributors of the month, the evolution of commits and active contributors for each month over the last year and monitor the recent commits that are being done in the various Polkadot organisations. There are many benefits of getting the DotPulse project up and running: - - it offers a clear overview on the open source development that is being done across the various Polkadot organizations, by having all the required data aggregated in one place - - acknowledges the contributors of the month - - displays the active contributors for each month over the last year - - shows the evolution of the number of commits made on GitHub by developers throughout the entire Polkadot ecosystem - - outlines the recent commits - + +- it offers a clear overview on the open source development that is being done across the various Polkadot organizations, by having all the required data aggregated in one place +- acknowledges the contributors of the month +- displays the active contributors for each month over the last year +- shows the evolution of the number of commits made on GitHub by developers throughout the entire Polkadot ecosystem +- outlines the recent commits + ## Team :busts_in_silhouette: ### Team members - - Andreea - Team Leader - - Cristina - Full Stack Developer (JavaScript, React) - - Catalin - Full Stack Developer (JavaScript, React) - - Florin - UI/UX Designer (Sketch, Figma) +- Andreea - Team Leader +- Cristina - Full Stack Developer (JavaScript, React) +- Catalin - Full Stack Developer (JavaScript, React) +- Florin - UI/UX Designer (Sketch, Figma) ### Contact - **Contact Name:** Andreea Stefan - **Contact Email:** andreea.stefan@crosschainlabs.tech -- **Website:** https://www.crosschainlabs.tech/ +- **Website:** ### Legal Structure @@ -63,32 +64,32 @@ There are many benefits of getting the DotPulse project up and running: ### Team's experience -We’re CrossChain Labs, a team of of designer and software developers with hands-on experience on blockchain technology and development of decentralised applications, with previous experience as ConsenSys employees. Some of the latest dev-grants were for projects from Filecoin (https://filmarket.io/) and NEAR protocol (NEAR registrar, Audit Registry, near.link, Developer Dashboard) with tech stack: IPFS, Arweave, rust, react, go and javascript. +We’re CrossChain Labs, a team of of designer and software developers with hands-on experience on blockchain technology and development of decentralised applications, with previous experience as ConsenSys employees. Some of the latest dev-grants were for projects from Filecoin () and NEAR protocol (NEAR registrar, Audit Registry, near.link, Developer Dashboard) with tech stack: IPFS, Arweave, rust, react, go and javascript. We're creative, experienced, responsible, organised and do our best to make high quality work and bring ideas to life. ### Team Code Repos -- https://github.com/CrossChainLabs -- https://github.com/CrossChainLabs/near-registrar -- https://github.com/CrossChainLabs/audit-registry -- https://github.com/CrossChainLabs/near-dns -- https://github.com/CrossChainLabs/near-api-go -- https://github.com/CrossChainLabs/coredns-near -- https://github.com/CrossChainLabs/near-link -- https://github.com/CrossChainLabs/filmarket-contract +- +- +- +- +- +- +- +- Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. -- https://github.com/yellow-cube -- https://github.com/arctic-ash -- https://github.com/aliasccl +- +- +- ### Team LinkedIn Profiles (if available) -- https://www.linkedin.com/in/andreea-stefan-66740b20/ -- https://www.linkedin.com/in/cristina-varteniuc-6b3121224/ -- https://www.linkedin.com/in/catalin-vlad-48b828229/ -- https://ro.linkedin.com/in/florin-gradinaru-73891bb +- +- +- +- ## Development Status :open_book: @@ -125,13 +126,13 @@ Since Polkadot has increasingly grown the open source developer ecosystem, there | 9. | Implement the DotPulse APIs required by frontend | Statistics API that returns the overall number of commits, repositories, contributors, PRs | | 10. | Implement the DotPulse APIs required by frontend | Contributors API that returns the list of contributors of the month based on the number of commits over the last month | | 11. | Implement the DotPulse APIs required by frontend | Issues APIs that return the total number of issues, the number of closed and open issues | -| 12. | Implement the DotPulse APIs required by frontend | Commits API that returns the total number of commits per month +| 12. | Implement the DotPulse APIs required by frontend | Commits API that returns the total number of commits per month ### Milestone 2 - **Estimated duration:** 4 weeks - **FTE:** 3.5 -- **Costs:** 21,500 USD, +- **Costs:** 21,500 USD, - NOTE: The M2 calculation includes the cloud infrastructure cost estimated at $1,000 | Number | Deliverable | Specification | @@ -140,7 +141,7 @@ Since Polkadot has increasingly grown the open source developer ecosystem, there | 0b. | Documentation | We will provide both documentation of the code and a basic video tutorial that explains how a user can easily use DotPulse app | | 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | -| 0e. | Article | We will publish an article that explains what was achieved as part of the grant and how users can benefit the most from DotPulse functionalities. | +| 0e. | Article | We will publish an article that explains what was achieved as part of the grant and how users can benefit the most from DotPulse functionalities. | | 1. | Implement the DotPulse APIs required by frontend | Active contributors API that returns the number of active developers for each month over the last year | | 2. | Implement the DotPulse APIs required by frontend | Recent commits API that returns the list of recent commits across all Polkadot repositories over the last 30 days | | 3. | Build the DotPulse dashboard | Display the statistics top section with the overall number of commits, repositories, contributors and PRs | @@ -157,6 +158,7 @@ Since Polkadot has increasingly grown the open source developer ecosystem, there ## Future Plans To drive adoption of the DotPulse platform, CrossChain Labs will: + - create a YouTube video tutorial showcasing the DotPulse functionalities and usage - distribute it via Polkadot Discord channels - add Google Analytics to track users engagement in order to adapt and improve accordingly diff --git a/applications/Doter.md b/applications/Doter.md index c0dc014a07b..fcbca68cef9 100644 --- a/applications/Doter.md +++ b/applications/Doter.md @@ -1,9 +1,7 @@ -# Open Grant Proposal - -* **Project Name:** Doter (A browser extension wallet for Polkadot) -* **Team Name:** ChainBridge network -* **USDT Payment Payment Address:** 0x9bb9af8f2fd4487c88f1352fdd32a3ec2b6d28b6(ERC20) +# Doter (A browser extension wallet for Polkadot) +- **Team Name:** ChainBridge network +- **USDT Payment Payment Address:** 0x9bb9af8f2fd4487c88f1352fdd32a3ec2b6d28b6(ERC20) ## Project Overview @@ -15,11 +13,14 @@ We are committed to building Doter into a truly user-centric browser extension w Now, we can already [install Doter](https://chrome.google.com/webstore/detail/doter/abamjefkidngfegdjbmffdmbgjgpaobf) in the Google Chrome extension market. -### Project Details +### Project Details #### Functional structure + ![img](https://uploader.shimo.im/f/4XnoevPmkhO6ZSqT.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTkxMzk5MDEsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE5MTM4MTAxLCJ1IjowfQ.gkX36NMe-V9je08Ofh2mFgSEzsJ_k-YnHBsaVxo2Lyo) + #### Core components + The Doter consists of several core components： Account part: with the help of Doter, users can create account, retrieve account, and backup account conviently. Through these accounts, users can complete a series of core interactions with the Polkadot ecosystem. @@ -31,47 +32,53 @@ Query part: Doter provides many portals to facilitate users to query some common Setting part: with the help of this part, users can easily set the extension to make it closer to their habits. A lot of common community public packages are used to ensure the consistency and correctness of business logic in Doter, such as @polkadot/api, @polkadot/keyring, @polkadot/util etc. In the specific development process, we use a lot of encapsulated public packages based on web technology, so as to ensure a good experience in the browser. + #### UI prototype -* Create wallet +- Create wallet ![img](https://uploader.shimo.im/f/AvN1H55TIy37Mng1.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Import wallet +- Import wallet ![img](https://uploader.shimo.im/f/L2KdTUpEdaLUZFV7.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Transfer and receive +- Transfer and receive ![img](https://uploader.shimo.im/f/ls2kbqxw9OkhNEbz.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Settings +- Settings ![img](https://uploader.shimo.im/f/P23QRARBLwBGQSS0.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Manage +- Manage ![img](https://uploader.shimo.im/f/1YOSQkFmPIg8tUGl.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Transaction records, etc. +- Transaction records, etc. ![img](https://uploader.shimo.im/f/q1gFLzRqrYdAvnxO.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Governance +- Governance ![img](https://uploader.shimo.im/f/ppL6L43PPaQuic1g.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Signature and injection +- Signature and injection ![img](https://uploader.shimo.im/f/lvYJi1DQ4ASFCcIF.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Staking +- Staking ![img](https://uploader.shimo.im/f/MDALPQL6MM0DjPcg.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -### Ecosystem Fit +### Ecosystem Fit #### Competitive product analysis + Polkadot's browser extension wallet, the currently known competitor is Enzyme. -* From the perspective of feature richness, the functional modules achieved by Doter's first milestone have exceeded Enzyme (Recently, we have completed the first milestone), and more functional modules that will serve the Polkadot ecology will be implemented in the plan. -* From the perspective of UI experience, Doter is a real user-centric wallet. A clear and concise UI experience is more attractive to users, and Doter has achieved Chinese and English language switching, which has a wider potential user group. -* From the perspective of github maintenance frequency, Enzyme has not been maintained for more than 1 year. In contrast, Doter has a clear development roadmap and the code base is constantly updated. + +- From the perspective of feature richness, the functional modules achieved by Doter's first milestone have exceeded Enzyme (Recently, we have completed the first milestone), and more functional modules that will serve the Polkadot ecology will be implemented in the plan. +- From the perspective of UI experience, Doter is a real user-centric wallet. A clear and concise UI experience is more attractive to users, and Doter has achieved Chinese and English language switching, which has a wider potential user group. +- From the perspective of github maintenance frequency, Enzyme has not been maintained for more than 1 year. In contrast, Doter has a clear development roadmap and the code base is constantly updated. #### The difference between Doter and polkadot.js extension -Polkadot.js extension is an official account management tool, Compared with polkadot.js extension, Doter's positioning is not only an account management tool. -Doter will also implements a series of common functions in Polkadot ecology, such as Transfer and receive, query transaction records, wallet management, easy-to-operate on-chain governance modules, etc. This means that doter can not only interact well with other dapps, but also independently complete the functions mentioned above, providing users with a one-stop experience, which polkadot.js extension does not have. + +Polkadot.js extension is an official account management tool, Compared with polkadot.js extension, Doter's positioning is not only an account management tool. +Doter will also implements a series of common functions in Polkadot ecology, such as Transfer and receive, query transaction records, wallet management, easy-to-operate on-chain governance modules, etc. This means that doter can not only interact well with other dapps, but also independently complete the functions mentioned above, providing users with a one-stop experience, which polkadot.js extension does not have. In addition, Doter will also provide a completely user-centric UI experience to make it easier for users to participate in the Polkadot ecosystem. #### Product direction and advantages -Analogous to MetaMask, in the current industry environment, browser extension wallets are more convenient to interact with DApp than mobile wallets. Doter is positioned as a browser extension wallet and has a first-mover advantage in the product direction. + +Analogous to MetaMask, in the current industry environment, browser extension wallets are more convenient to interact with DApp than mobile wallets. Doter is positioned as a browser extension wallet and has a first-mover advantage in the product direction. At the same time, most of the current mobile wallets connected to Polkadot are not dedicated to the Polkadot ecosystem, and there is no in-depth development based on Polkadot. Doter focuses on the Polkadot ecosystem and enables more users to participate in the Polkadot ecosystem through customized and truly friendly interactive experience. #### How to maintain the wallet + In the near future, Our team will have someone in charge of maintaining the Doter, Update at least once a month to fix bugs or improve the experience，to making Doter as close as possible to mature browser extension in other ecosystems(such as Ethereum) Simultaneously, we will build our own community as soon as possible. We believe that a solid community is the foundation for Doter to seize the market, Through word of mouth from seed users, we will accumulate the first batch of users. After completing all the milestones, we will place advertisements in a number of blockchain media, and rapidly expand the number of users through advertising. Secondly, we will embed a frequently used DApp in the wallet and cultivate user habits through this, so that Doter will gradually become the portal of the Polkadot ecosystem. @@ -81,64 +88,77 @@ In summary, we have appropriate market timing, clear product direction, reliable ## Team ### Team members -* Guan Yu -* Gao Jianli + +- Guan Yu + +- Gao Jianli ### Contact -* **Contact Name:** Gao Jianli -* **Contact Email:** dianluyuanli@foxmail.com -* **Website:** Doter is currently maintained on [Github](https://github.com/ChainBridgeNetworkTeam/Doter), no website has been created yet -### Legal Structure +- **Contact Name:** Gao Jianli + +- **Contact Email:** dianluyuanli@foxmail.com +- **Website:** Doter is currently maintained on [Github](https://github.com/ChainBridgeNetworkTeam/Doter), no website has been created yet + +### Legal Structure + Doter is maintained by the [ChainBridgeNetworkTeam](https://github.com/ChainBridgeNetworkTeam), and no company entity has been created yet, The following is our communication information. -* Mailing address: 504, Building 16, Lane 270, Maotai Road, Changning District, Shanghai, China -* E-mail：dianluyuanli@foxmail.com, muskshi@foxmail.com -* Twitter：ChainBridgeNet1 -* WeChat Official Accounts：ChainBridgeNetwork + +- Mailing address: 504, Building 16, Lane 270, Maotai Road, Changning District, Shanghai, China +- E-mail：dianluyuanli@foxmail.com, muskshi@foxmail.com +- Twitter：ChainBridgeNet1 +- WeChat Official Accounts：ChainBridgeNetwork ### Team's experience -* Guan Yu + +- Guan Yu He participated in Polkadot's official crowdfunding campaign in 2017 and has continued to be active in the Polkadot community ever since. From July 2018 to the present, he has been serving as a product manager for Pinduoduo Inc.(listed on NASDAQ), responsible for building core business modules such as CPS. He has 3 years of experience in large-scale Internet companies, is familiar with the development and maintenance of large-scale products, and is good at leading the business from 0 to 1 and achieving rapid growth. -* Gao Jianli +- Gao Jianli He joined Pinduoduo Inc.（listed on NASDAQ）in 2018 and became a full-time front-end development engineer. Responsible for the maintenance of the website promotion page, maintenance and development of the weChat applet architecture Project deployment and launch, development of productivity tools. He has three years of development experience, is familiar with project deployment and front-end technology stack, and is keen on Polkadot ecological technology trends. -Personal Code Repos：https://github.com/dianluyuanli-wp +Personal Code Repos： ### Team Code Repos -* https://github.com/ChainBridgeNetworkTeam/Doter + +- ### Team LinkedIn Profiles -Guan Yu：https://www.linkedin.com/in/yu-guan-482624155/ -Gao Jianli：https://www.linkedin.com/in/jianli-gao-6785a1140/ + +Guan Yu： +Gao Jianli： ## Development Roadmap **In particular, we have completed the basic module of the Doter wallet, and the extension program has been put on the Google extension market. You can already [install](https://chrome.google.com/webstore/detail/doter/abamjefkidngfegdjbmffdmbgjgpaobf) and use Doter.** The following is a list of functions that have been implemented -* Create and import wallets on Polkadot -* Transfer and receive on Polkadot -* Backup wallet on Polkadot -* Query transaction records on Polkadot -* Referendum on the chain on Polkadot -* Switch multiple wallets on Polkadot -* Manage address book on Polkadot -* Switch language on Polkadot + +- Create and import wallets on Polkadot +- Transfer and receive on Polkadot +- Backup wallet on Polkadot +- Query transaction records on Polkadot +- Referendum on the chain on Polkadot +- Switch multiple wallets on Polkadot +- Manage address book on Polkadot +- Switch language on Polkadot ### Overview -* Total Estimated Duration: 2 month -* Full-time equivalent (FTE): 34 -* Total Costs: $16,150 + +- Total Estimated Duration: 2 month + +- Full-time equivalent (FTE): 34 +- Total Costs: $16,150 ### Milestone + #### M1: Injection and signature -* Estimated Duration: 1 month -* FTE: 14 -* Costs: $6,650（2 contributors * 7 FTE * $475/FTE） +- Estimated Duration: 1 month +- FTE: 14 +- Costs: $6,650（2 contributors *7 FTE* $475/FTE） | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -146,14 +166,14 @@ The following is a list of functions that have been implemented | 0b. | Description | We will implement wallet injection and transaction signature on Polkadot, and optimize the UI experience of existing funcctions. | | 0c. | Delivery time | Mid May | | 0d. | How to verify | It is expected that in Mid May, you can install the latest version of Doter in the Google Extended Market and verify the functional modules promised in the milestone. In addition, you can also verify through integration tests, We will provide yarn commond for anyone who want to run the unit test scripts and check the results. | -| 1. | Core component | * Wallet injection on Polkadot
          * Transaction signature on Polkadot
          * Optimize account creation, transfer, account management and other functions to improve user experience +| 1. | Core component | * Wallet injection on Polkadot
          * Transaction signature on Polkadot
          * Optimize account creation, transfer, account management and other functions to improve user experience | #### M2: Support kusama network -* Estimated Duration: 1 month -* FTE: 20 -* Costs: $9,500（2 contributors * 10 FTE * $475/FTE） +- Estimated Duration: 1 month +- FTE: 20 +- Costs: $9,500（2 contributors *10 FTE* $475/FTE） | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -161,11 +181,12 @@ The following is a list of functions that have been implemented | 0b. | Description | We will support all functional modules that have been implemented on Polkadot. | | 0c. | Delivery time | Mid June | | 0d. | How to verify | It is expected that in mid June, you can install the latest version of Doter in the Google Extended Market and verify the functional modules promised in the milestone. In addition, you can also verify through integration tests, We will provide yarn commond for anyone who want to run the unit test scripts and check the results. | -| 1. | Core component | * Create and import wallets on Kusama
          * Transfer and receive on Kusama
          * Backup wallet on Kusama
          * Query transaction records on Kusama
          * Referendum on the chain on Kusama
          * Switch multiple wallets on Kusama
          * Manage address book on Kusama
          * Switch language on Kusama
          * wallet injection and signature on Kusama +| 1. | Core component | * Create and import wallets on Kusama
          * Transfer and receive on Kusama
          * Backup wallet on Kusama
          * Query transaction records on Kusama
          * Referendum on the chain on Kusama
          * Switch multiple wallets on Kusama
          * Manage address book on Kusama
          * Switch language on Kusama
          * wallet injection and signature on Kusama | ## Community engagement -This is a tutorial posted on medium：https://chainbridgenetwork.medium.com/polkadots-browser-extension-wallet-doter-ac8cd91a5bf3 + +This is a tutorial posted on medium： ## Future Plans @@ -174,6 +195,7 @@ Doter’s development team is ChainBridgeNetworkTeam. As the name suggests, our Doter is our first product. We believe that with the launch of the parachain, Doter will act as an important interaction bridge in the Polkadot ecosystem. After completing the development of 2 milestones, we will design Doter version 2.0. In version 2.0, users can easily manage private digital assets without memorizing mnemonic words. This will be achieved through an innovative technology. We believe in version 2.0 Doter will greatly reduce the threshold for users to use wallets, making Doter a real bridge between Polkadot and ordinary users. ## Additional Information + ChainBridgeNetworkTeam has just been established for two months, but we have completed the basic module of Doter, and have designed the other two milestones. In the next two months, we will deliver all pre-designed functional modules. So far, we have developed at our own expense, but in order to have sufficient funds to support the realization of our long-term vision, we will try to obtain the support of investment institutions. diff --git a/applications/EverlastingCash.md b/applications/EverlastingCash.md index f077809f462..30ae2c1fc7a 100644 --- a/applications/EverlastingCash.md +++ b/applications/EverlastingCash.md @@ -1,57 +1,62 @@ -# Open Grant Proposal +# Everlasting Cash -* **Project Name:** Everlasting Cash -* **Team Name:** Cycan Technologies -* **Payment Address:** ETH address: 0x722043b40dEb4656a103aF03Fd8E781d0146d3F6 -* **Status:**: Terminated +- **Team Name:** Cycan Technologies +- **Payment Address:** ETH address: 0x722043b40dEb4656a103aF03Fd8E781d0146d3F6 +- **Status:**: Terminated -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview - * While the incumbent stablecoins in the market have served the purpose of stabilizing the prices of cryptocurrencies, there are obvious limitations. Fiat-backed stablecoins such as USDT are not decentralized with the risk of being compromised by the central entity; while crypto-backed stablecoins are more vulnerable to price instability, since they are pegged to other cryptocurrencies. The risk of a possible crash for non-collateralized stablecoins is relatively high, since they lack collateral to liquidate the coin back into, while commodity-backed stablecoins might have liquidity problems as physical assets are not so easily liquidated. - * Everlasting Cash is a new kind of stablecoin which solves these issues with a truly decentralized, anti-inflation and stable product with reserves. - * Everlasting Cash a.k.a. ELC is a decentralized algorithmic stablecoin using Substrate with a unique reserve system, i.e. a hybrid of a crypto-collateralized and an algorithmic stablecoin mechanism, with the collateralized mechanism providing the underlying value guarantee, and the algorithmic mechanism incentivizing the participants on one hand, and hedging the downside risk when the demand for the stablecoin is insufficient on the other. - * ELC aims to provide users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. -### Project Details +- While the incumbent stablecoins in the market have served the purpose of stabilizing the prices of cryptocurrencies, there are obvious limitations. Fiat-backed stablecoins such as USDT are not decentralized with the risk of being compromised by the central entity; while crypto-backed stablecoins are more vulnerable to price instability, since they are pegged to other cryptocurrencies. The risk of a possible crash for non-collateralized stablecoins is relatively high, since they lack collateral to liquidate the coin back into, while commodity-backed stablecoins might have liquidity problems as physical assets are not so easily liquidated. +- Everlasting Cash is a new kind of stablecoin which solves these issues with a truly decentralized, anti-inflation and stable product with reserves. +- Everlasting Cash a.k.a. ELC is a decentralized algorithmic stablecoin using Substrate with a unique reserve system, i.e. a hybrid of a crypto-collateralized and an algorithmic stablecoin mechanism, with the collateralized mechanism providing the underlying value guarantee, and the algorithmic mechanism incentivizing the participants on one hand, and hedging the downside risk when the demand for the stablecoin is insufficient on the other. +- ELC aims to provide users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. + +### Project Details Everlasting Cash (ELC) contracts are written in Rust language and can be deployed to Polkadot/Kusama parachain (ink! pallet). #### Technical Design Overview - + #### Tokens + 1) Everlasting Parachain Token - ELP ELP is a native token of the Everlasting Parachain (a parachain on Kusama). Participants are able to send ELP to the ELC multifunction contract as reserve assets to exchange ELC: according to the different system liability ratios, the contract will return both ELC and rELP, or rELP only to participants (see “Reserve” paragraph below). 2) ELC Token -ELC token is the stablecoin within the ELC contract system, with the initial pegged rate of 1 USD value in the year of 2021. The pegged rate varies over time based on inflation and depends on whether its supply expands or shrinks based on the system LR. +ELC token is the stablecoin within the ELC contract system, with the initial pegged rate of 1 USD value in the year of 2021. The pegged rate varies over time based on inflation and depends on whether its supply expands or shrinks based on the system LR. 3) rELP Token rELP token is a risk asset in the ELC system (an equity in the system). Participants are able to add rELP liquidity to the multifunction pool, which could be realized by sending ELP to ELC contract. The system encourages user to do long-term liquidity mining so as to keep the reserve pool more stable with liquidity. #### Multifunction Pool + 1) Reserve Participants can send ELPs to the ELC system in exchange for both ELC and rELP, or rELP alone, depending on what the system liability ratios are. When the system LR is less than 30%, participants who send ELPs to the ELC system can obtain a certain amount of ELC and rELP minted and the LR of the system remains unchanged. When the system LR is higher than 30%, participants who send ELPs to the ELC system will only get rELP, and this can decrease LR. 2) Risk Reserve Fund -The risk reserve fund includes two assets (ELPs and ELCs). The purpose of the Risk Reserve Fund is to keep the ELC prices floating between 98% and 102% of the ELC aim price (ELCaim). For example, 1 million ELPs out of the overall 21 million of ELPs initial issuance are used as initial risk reserves. +The risk reserve fund includes two assets (ELPs and ELCs). The purpose of the Risk Reserve Fund is to keep the ELC prices floating between 98% and 102% of the ELC aim price (ELCaim). For example, 1 million ELPs out of the overall 21 million of ELPs initial issuance are used as initial risk reserves. Such risk reserve fund is used as follows: when ELP price is lower than 98% of ELCaim, the ELC system will swap ELP for ELC until all ELP in the pool are swapped into ELC to keep the price back to ELCaim. When ELP price is higher than 102% of ELCaim, the ELC system will swap ELC to ELP until all ELCs in the pool are swapped into ELP to keep the price back to ELCaim. 3) Liquidity Mining -Participants who have deposited ELPs to the reserve pool contract, can obtain rELP and use rELP to participate in the liquid mining. In order to maintain the size of reserves, participants are encouraged to do long-term liquidity mining. Participants who join liquidity mining will earn more tokens if they hold the tokens longer. +Participants who have deposited ELPs to the reserve pool contract, can obtain rELP and use rELP to participate in the liquid mining. In order to maintain the size of reserves, participants are encouraged to do long-term liquidity mining. Participants who join liquidity mining will earn more tokens if they hold the tokens longer. #### Inflation Governance + The generation time of ELP is 6 seconds per block. The ELP target price rises every 10,000 blocks in K, K is an anti-inflation factor. The inflation factor K can be adjusted through the ELP governance mechanism. rELP holders can vote for the adjustment of the anti-inflation factor K when the USD inflation goes into hyperinflation. #### Oracle -The oracle of reserve asset ELP and stablecoin ELC is implemented with Chainlink-Polkadot. We utilize Chainlink's decentralized Oracle network to quickly and securely connect end-to-end all the inputs and outputs of smart contracts to avoid pitfalls associated with deploying our own Oracle, such as long delays, additional charges, and even fatal security vulnerabilities. + +The oracle of reserve asset ELP and stablecoin ELC is implemented with Chainlink-Polkadot. We utilize Chainlink's decentralized Oracle network to quickly and securely connect end-to-end all the inputs and outputs of smart contracts to avoid pitfalls associated with deploying our own Oracle, such as long delays, additional charges, and even fatal security vulnerabilities. #### Contract + 1) ELC - Minting and burning of the ELC token Mints ELC amount to the recipient account. -Burns ELC amount from the account. +Burns ELC amount from the account. 2) rELP - Minting and burning of the rELP token Mints rELP amount to the recipient account. @@ -63,10 +68,11 @@ Mints some rELC amount, in exchange for some ELP amount. Mints some ELC and rELP amounts, in exchange for some ELP amount. Returns the amount of ELC and rELP. -ELCaim(after adjustment) = ELCaim(before adjustment) * (1+K) -LR = Value/P(ELP) * Amount(ELP) +ELCaim(after adjustment) = ELCaim(before adjustment) *(1+K) +LR = Value/P(ELP)* Amount(ELP) Where: + - Value is the value of the ELCs that have been issued - P isthe price of ELP - Amount is the number of ELP in reserve pool @@ -74,28 +80,28 @@ Where: When LR is lower than 0.3, the ELC system mints amounts of ELCs and rELPs, in exchange for amount of ELPs. -△Amount(rELP) = p(ELP) * △Amount(ELP) * (1-LR)/p(rELP) -△Amount(ELC) = p(ELP) * △Amount(ELP) * LR +△Amount(rELP) = p(ELP) *△Amount(ELP)* (1-LR)/p(rELP) +△Amount(ELC) = p(ELP) *△Amount(ELP)* LR When LR is higher than 0.3, the ELC system mints amount of rELPs only, in exchange for amount of ELPs. △Amount(rELP) = p(ELP) * △Amount(ELP) /p(rELP) When ELC is higher than 102% of ELCaim and LR <= 0.7, the ELC system issues amount of ELC to rELP holders (95% of issued ELC) and the pool (5% of issued ELC). When ELC is higher than 102% of ELCaim, if the multifunction pool has ELC, it swaps amount of ELCs for amount of ELPs, decreasing ELC supply. -When ELC is lower than 98% of ELCaim, the multifuncitonal pool swaps amount of ELPs for amount of ELCs. +When ELC is lower than 98% of ELCaim, the multifuncitonal pool swaps amount of ELPs for amount of ELCs. When ELC is higher than 102% of ELCaim and LR is <= 0.7, when min (weighted average price of ELC 24 hours, weighted average price of ELC 1 hour) > $1, additional ELCs are issued, additional ELC will allocate to rELP liquidity provider (95% of issued ELC) and the multifunction pool (5% of issued ELC). Number of additional ELCs for the day = min (weighted average price of ELCs 24 hours before monitoring point, weighted average price of ELCs 1 hour before monitoring point) /100 * number of ELCs before additional issuance. -Number of ELCs obtained by the rELP liquidity miner = number of additional ELCs issued on that day * 95% * miner’s share +Number of ELCs obtained by the rELP liquidity miner = number of additional ELCs issued on that day *95%* miner’s share Number of ELCs added to the multifunction pool as risk reserve fund = number of additional ELCs issued on the day * 5% When ELC is higher than 102% of ELCaim and LR > 0.7, the system will not issue any new ELCs, but will use the risk reserve fund (ELC) to swap amount of ELC for amount of ELP, which can decrease ELC price. -### Ecosystem Fit +### Ecosystem Fit Everlasting Cash is the stablecoin for the Cycan Network, which is a larger effort to build a decentralized autonomous trust (DAT) protocol for everyone to build business models in fintech and other fields within the Polkadot ecosystem. On the Cycan Network, for instance, anyone can launch a DeFi project, or build an investment portfolio and participate in the decision-making process for any DeFi product on the network. @@ -106,35 +112,44 @@ The Cycan Network (CYA) is an parachain built on the Polkadot network. The Everl ELC has a stable target pricing mechanism, called ELCaim. ELCaim is initially set as 1 USD and the pegged rate of ELCaim will be continuously adjusted and stabilized based on the anti-inflation factor (K), forming the anti-inflation algorithmic stablecoin mechanism. ELC not only uses crypto currencies as systemic reserves to decide the basic value of stablecoins, but also uses algorithms to control the supply of ELC so that the prices are at the same level of ELCaim. Users can use other cryptocurrencies including CYA, ELP, DOT, KSM, BTC, ETH and other digital assets proposed by the Cycan community to generate Everlasting Cash in the ELC protocol. Based on the Polkadot/Kusama ecosystem, Everlasting Cash will be playing a huge role in the future DeFi market, thanks to: -1. The adoption a crypto-collateralized mechanism to ensure the basic value of ELC. + +1. The adoption a crypto-collateralized mechanism to ensure the basic value of ELC. 2. The utilization of a reserve-based liquidity mining mechanism to issue additional ELC, so that ELC grows in an orderly manner with the expansion of demand. 3. The anti-inflation model, and using the anti-inflation factor K to adjust the ELCaim (the pegged rate). The annual appreciation rate of ELC is roughly the same as the inflation rate of USD. -4. The buffer mechanism with reserves for price falls, which avoid the death loop trap of algorithmic stablecoins. +4. The buffer mechanism with reserves for price falls, which avoid the death loop trap of algorithmic stablecoins. The ELC reserve pool will prioritize the tokens from the Polkadot system to build a solid stablecoin ecosystem. ## Team :busts_in_silhouette: -The team beyond Everlasting Cash is the Cycan team, an early-stage core pool of talents from around the world, with a background in finance, blockchain development and large-scale software architectures serving multiple industries, business development and media. + +The team beyond Everlasting Cash is the Cycan team, an early-stage core pool of talents from around the world, with a background in finance, blockchain development and large-scale software architectures serving multiple industries, business development and media. Cycan has a core team of developers numbering 10, including a development leader, 7 Rust developers, 1 product manager, and 1 front-end engineer. ### Team members + Cycan is directed by the following key roles: -* Donald Gao: founder, financial model designer -* Michele Ruberl, global tech partner, IT architect -* Vivi Lin, global partner, CMO + +- Donald Gao: founder, financial model designer +- Michele Ruberl, global tech partner, IT architect +- Vivi Lin, global partner, CMO ### Contact -* **Contact Name:** Donald Gao -* **Contact Email:** Donald@cycan.network -* Website http://cycan.network -### Legal Structure -* **Registered Address:** to be registered. -* **Registered Legal Entity:** Cycan Foundation is being registered in Singapore, ETA March 2021. +- **Contact Name:** Donald Gao + +- **Contact Email:** Donald@cycan.network +- Website http://cycan.network + +### Legal Structure + +- **Registered Address:** to be registered. + +- **Registered Legal Entity:** Cycan Foundation is being registered in Singapore, ETA March 2021. ### Team's experience + Cycan’s team has a long experience in the blockchain technology development and financial model designs. The team has developed public chains similar to Ethereum, cross-chain bridges connecting DPOS-based side chain and the notary network, and the open consortium chain with the rPBFT consensus mechanism. The team also has rich experience in smart contract development, including the Bancor-based decentralized transaction protocol, decentralized identity, distributed domain registration and auction, decentralized stable coin protocols, etc. @@ -147,80 +162,95 @@ Lastly, the team has a consolidated architectural and devops experience both in ### Team Code Repos -* ELP-Runtime-node: https://github.com/CycanTech/ELP-Runtime-node -* ELC-contracts: https://github.com/CycanTech/ELC + +- ELP-Runtime-node: https://github.com/CycanTech/ELP-Runtime-node + +- ELC-contracts: https://github.com/CycanTech/ELC ### Team LinkedIn Profiles -* https://www.linkedin.com/in/donald-gao-6bab74206/ -* https://www.linkedin.com/in/vivi-lin-1862276/ -* https://www.linkedin.com/in/mikrub/ + +- https://www.linkedin.com/in/donald-gao-6bab74206/ + +- https://www.linkedin.com/in/vivi-lin-1862276/ +- https://www.linkedin.com/in/mikrub/ -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: ### Overview -* **Total Estimate Duration:** 14 weeks -* **Full-time Equivalent(FTE):** 4 -* **Total cost:** 1500 USD (we accept up to 100% of payment in crypto currencies that are equivalent to $1,500 including DAI) + +- **Total Estimate Duration:** 14 weeks + +- **Full-time Equivalent(FTE):** 4 +- **Total cost:** 1500 USD (we accept up to 100% of payment in crypto currencies that are equivalent to $1,500 including DAI) ### Milestone 1 – Implement ELC contracts -* **Total Estimate Duration:** 8 weeks -* **Full-time Equivalent(FTE):** 2 -* **Total cost:** 1000 USD -* **Task:** to fulfill the ELC contracts development based on ink! + +- **Total Estimate Duration:** 8 weeks + +- **Full-time Equivalent(FTE):** 2 +- **Total cost:** 1000 USD +- **Task:** to fulfill the ELC contracts development based on ink! | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use ELC contract. | -| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | -| 1. | ELC contracts | Develop ELC contract implement ELC whitepaper | -| 1a. | Anti-Inflation Factor K & On-Chain Governance | As the Polkadot parachain, Cycan/ELP network generates a block every 6 seconds or so, and the ELCaim increases by K every 10,000 blocks. In the ELC network, K can be adjusted through the on-chain governance mechanism, which can be decided by public voting in the community. | -| 1b. | Liability Ratio | To swap digital assets into the ELC contract, in which one can obtain both ELC and the risk assets(rXXX) or only the risk asset(rXXX). The difference will be defined by the Liability Ratio(marked as LR). | -| 1c. | ELC Supply Expansion mechanism | When the prices of ELC exceed ELCaim, additional ELC will be issued and automatically allocated to the risk asset holders. | -| 1d. | ELC Supply Contraction | When the prices of ELC go lower than 0.98 ELCaim, the circulating ELC will be repurchased by the risk reserve fund, and this part of ELC will be temporarily taken out of circulation; when the prices of ELC start to go over ELCaim, the ELC will be sold with priority by the risk reserve fund to recover the reserve. | -| 1e. | Oracle Price acquirement | The oracle price adopts the dual price mechanism of Parachain DEX and Chainlink (or Zenlink). | +| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use ELC contract. | +| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | +| 1. | ELC contracts | Develop ELC contract implement ELC whitepaper | +| 1a. | Anti-Inflation Factor K & On-Chain Governance | As the Polkadot parachain, Cycan/ELP network generates a block every 6 seconds or so, and the ELCaim increases by K every 10,000 blocks. In the ELC network, K can be adjusted through the on-chain governance mechanism, which can be decided by public voting in the community. | +| 1b. | Liability Ratio | To swap digital assets into the ELC contract, in which one can obtain both ELC and the risk assets(rXXX) or only the risk asset(rXXX). The difference will be defined by the Liability Ratio(marked as LR). | +| 1c. | ELC Supply Expansion mechanism | When the prices of ELC exceed ELCaim, additional ELC will be issued and automatically allocated to the risk asset holders. | +| 1d. | ELC Supply Contraction | When the prices of ELC go lower than 0.98 ELCaim, the circulating ELC will be repurchased by the risk reserve fund, and this part of ELC will be temporarily taken out of circulation; when the prices of ELC start to go over ELCaim, the ELC will be sold with priority by the risk reserve fund to recover the reserve. | +| 1e. | Oracle Price acquirement | The oracle price adopts the dual price mechanism of Parachain DEX and Chainlink (or Zenlink). | ### Milestone 2 – Extend functions of the ELC contract. -* **Total Estimate Duration:** 6 weeks -* **Full-time Equivalent(FTE):** 2 -* **Total cost:** 500 USD -* **Task:** Implement new contract functions based on ink! and develop DAPP front-end. + +- **Total Estimate Duration:** 6 weeks + +- **Full-time Equivalent(FTE):** 2 +- **Total cost:** 500 USD +- **Task:** Implement new contract functions based on ink! and develop DAPP front-end. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use product. | -| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | -| 1a. | ELC contract extension: Liquidity Mining Pool | ELP reserves a certain percentage of tokens to reward participants generatingELC, which means that part of the tokens will be given to risk asset (rELP) holders. | -| 1b. | ELC contract extension: Risk Reserve Fund | 1) A total of 21 million ELPs, of which 1 million ELPs are deposited into the risk reserve fund as the initial risk reserve. 2) In the ELC supply expansion process, 5% of the additional ELC issued through the algorithmic mechanism is converted into ELP and deposited in the risk reserve fund. | -| 2a. | ELC Dapp | 1) ELC generation function. 2) Redemption of the pledged assets function. 3) ELC price, issuance volumes, risk assets, debt ratios and other query functions. 4) Liquidity mining function. And integrate with the wallet. | +| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use product. | +| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | +| 1a. | ELC contract extension: Liquidity Mining Pool | ELP reserves a certain percentage of tokens to reward participants generatingELC, which means that part of the tokens will be given to risk asset (rELP) holders. | +| 1b. | ELC contract extension: Risk Reserve Fund | 1) A total of 21 million ELPs, of which 1 million ELPs are deposited into the risk reserve fund as the initial risk reserve. 2) In the ELC supply expansion process, 5% of the additional ELC issued through the algorithmic mechanism is converted into ELP and deposited in the risk reserve fund. | +| 2a. | ELC Dapp | 1) ELC generation function. 2) Redemption of the pledged assets function. 3) ELC price, issuance volumes, risk assets, debt ratios and other query functions. 4) Liquidity mining function. And integrate with the wallet. | ## Future Plans + Our team would like to make continuous contributions to the Substrate and Polkadot ecosystems. Our future plans are as follows: - • Everlasting Cash is only deployed in the Polkadot ecosystem, through the Runtime module using the Substrate framework. - • The ELC reserve pool will prioritize tokens from the Polkadot system to build a solid stablecoin ecosystem. - • To provide the users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. + • Everlasting Cash is only deployed in the Polkadot ecosystem, through the Runtime module using the Substrate framework. + • The ELC reserve pool will prioritize tokens from the Polkadot system to build a solid stablecoin ecosystem. + • To provide the users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. Everlasting Cash will exist as an independent asset in the Polkadot ecosystem, and will also power the Cycan decentralized autonomous trust (DAT) on the path to revolutionize trust in the financial market. -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: + +- What work has been done so far? -* What work has been done so far? - 1) The development of the initial version of the Substrate-based Pheonix test chain has been completed, supporting the WASM and EVM virtual machines. - 2) The DAO self-governance Runtime module and the application for the access to the Rococo test network are in progress. - 3) The development plan for the ELC contract has been formulated and the development is in progress. + 1) The development of the initial version of the Substrate-based Pheonix test chain has been completed, supporting the WASM and EVM virtual machines. + 2) The DAO self-governance Runtime module and the application for the access to the Rococo test network are in progress. + 3) The development plan for the ELC contract has been formulated and the development is in progress. + +- Are there are any teams who have already contributed (financially) to the project? -* Are there are any teams who have already contributed (financially) to the project?
           No -* Have you applied for other grants so far?
          +- Have you applied for other grants so far? +  No -* Are there any other project similar to yours?
          +- Are there any other project similar to yours? +  To the best of our knowledge, there is no project about anti-inflation stablecoin that is similar to our project. Please let us know if there are any. diff --git a/applications/FIAT-on-off-ramp.md b/applications/FIAT-on-off-ramp.md index 17ed724d6c5..d0c4ccaba0d 100644 --- a/applications/FIAT-on-off-ramp.md +++ b/applications/FIAT-on-off-ramp.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# FIAT on-off-ramp -* **Project Name:** FIAT on-off-ramp * **Team Name:** element36 * **Payment Address:** Ethereum 0x56788E08C97d2677DAdED801e69bfE5D33ddACD5 diff --git a/applications/Faucet.md b/applications/Faucet.md index 75c67389aa6..d138eced103 100644 --- a/applications/Faucet.md +++ b/applications/Faucet.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Generic sybil-resistant faucet -- **Project Name:** Generic sybil-resistant faucet - **Team Name:** MB Karolio reikalai - **Payment Address:** 0xc3e6eFA4D0847203dD4E19B7D114516Eb45840EC (DAI) - **Level:** 1 diff --git a/applications/Fennel_Protocol.md b/applications/Fennel_Protocol.md index 284a3e322c3..6851aee93c6 100644 --- a/applications/Fennel_Protocol.md +++ b/applications/Fennel_Protocol.md @@ -1,9 +1,8 @@ -# W3F Grant Proposal +# Fennel Protocol -* **Project Name:** Fennel Protocol -* **Team Name:** Fennel Labs -* **Payment Address:** 0xF505894841d53AaBDe6EdeA7C5970fFe3A0240b2 (DAI) -* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Team Name:** Fennel Labs +- **Payment Address:** 0xF505894841d53AaBDe6EdeA7C5970fFe3A0240b2 (DAI) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview :page_facing_up: @@ -15,10 +14,10 @@ This grant proposal describes the first step of a long-term plan to develop Fenn The background of the Whiteflag specification is as follows: -> Current armed conflicts are highly complex, because of the sheer number of parties involved: regular military forces, armed groups, peacekeeping forces, neutral parties such as journalists and non-governmental human-rights and aid organisations, civilians, refugees etc. Even though parties are opposing forces, or neutral organisations that do not want to show any affiliation, they do require to quickly and directly communicate to one or more other parties involved in the conflict in different situations. ->

          This is not new. The white flag is the original internationally recognized protective sign of truce or ceasefire, and request for negotiation. A white flag signifies to all that an approaching negotiator is unarmed, with an intent to surrender or a desire to communicate. ->

          This standard for a digital white flag protocol, the Whiteflag Protocol, provides a reliable means for both combatant and neutral parties in conflict zones to digitally communicate pre-defined signs and signals using blockchain technology. These sign and signals can also be used to communicate information about natural and man-made disasters, thus creating shared situational awareness beyond conflicts. ->

          All in all, the protocol forms the basis for a neutral and open network, the Whiteflag Network, for trusted real-time messaging between parties in conflicts and disaster response. +> Current armed conflicts are highly complex, because of the sheer number of parties involved: regular military forces, armed groups, peacekeeping forces, neutral parties such as journalists and non-governmental human-rights and aid organisations, civilians, refugees etc. Even though parties are opposing forces, or neutral organisations that do not want to show any affiliation, they do require to quickly and directly communicate to one or more other parties involved in the conflict in different situations. +>

          This is not new. The white flag is the original internationally recognized protective sign of truce or ceasefire, and request for negotiation. A white flag signifies to all that an approaching negotiator is unarmed, with an intent to surrender or a desire to communicate. +>

          This standard for a digital white flag protocol, the Whiteflag Protocol, provides a reliable means for both combatant and neutral parties in conflict zones to digitally communicate pre-defined signs and signals using blockchain technology. These sign and signals can also be used to communicate information about natural and man-made disasters, thus creating shared situational awareness beyond conflicts. +>

          All in all, the protocol forms the basis for a neutral and open network, the Whiteflag Network, for trusted real-time messaging between parties in conflicts and disaster response. One can find more details about the Whiteflag Protocol specification by clicking on these links: @@ -71,109 +70,125 @@ Though applications are planned, they are beyond scope for this proposal. ### Team members -* Sean Batzel -* Isaac Adams -* Andre Vanoncini -* Fernando Fonseca-Avalos -* Mateusz Plaza -* Jan Eberle +- Sean Batzel +- Isaac Adams +- Andre Vanoncini +- Fernando Fonseca-Avalos +- Mateusz Plaza +- Jan Eberle ### Contact -* **Contact Name:** Fennel Labs Core Team -* **Contact Email:** info@fennellabs.com -* **Website:** www.fennellabs.com +- **Contact Name:** Fennel Labs Core Team +- **Contact Email:** info@fennellabs.com +- **Website:** www.fennellabs.com ### Legal Structure -* **Registered Address:** 1309 Coffeen Avenue Suite 1200, Sheridan, Wyoming 82801 -* **Registered Legal Entity:** Fennel Labs, LLC. +- **Registered Address:** 1309 Coffeen Avenue Suite 1200, Sheridan, Wyoming 82801 +- **Registered Legal Entity:** Fennel Labs, LLC. ### Team's experience #### Sean Batzel -* Development Team co-lead for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. -* 2 years as lead and only developer of fEMR OnChain, a modular EMR software targeting eventual decentralization. -* 10 years of programming and software development experience -* 5 years of experience as lead/primary developer on expansive projects -* 2 years experience in remote development team coordination -* Graduate-level research experience studying blockchain’s uses in high-level information networks -* Dedicated focus on exploring use cases for blockchain and decentralized consensus beyond cryptocurrency and fusing Web 2 and Web 3 applications in a way that eases the industry’s transition to more decentralized computing + +- Development Team co-lead for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. + +- 2 years as lead and only developer of fEMR OnChain, a modular EMR software targeting eventual decentralization. +- 10 years of programming and software development experience +- 5 years of experience as lead/primary developer on expansive projects +- 2 years experience in remote development team coordination +- Graduate-level research experience studying blockchain’s uses in high-level information networks +- Dedicated focus on exploring use cases for blockchain and decentralized consensus beyond cryptocurrency and fusing Web 2 and Web 3 applications in a way that eases the industry’s transition to more decentralized computing #### Isaac Adams -* Succesfully launched [savvi](https://savvi.com) as tech lead and developed the jwt authentication, sign in/out, cart, and checkout features on the application while helping manage other developers working on the project -* Open source contributions: [added missing rpc method](https://github.com/harmony-one/sdk/pull/82) to harmony-one blockchain's npm package, [json ld transformer](https://github.com/parcel-bundler/parcel/pull/4397) for parcel v2, and extending usage of action-download-artifact to support the [github.ref variable](https://github.com/dawidd6/action-download-artifact/pull/55) -* Published author for [research](https://www.mdpi.com/2571-6182/1/1/1) on the degradation of antibiotics using a plasma apparatus -* 4 years of experience development experience on a wide range of projects, including web applications built using react/angular|.net core|SQL, labview applications for lab experiments, and devops/cloud operations -* 1 year of experience of being tech lead on two successfully launched web projects -* Graduated from Drexel University with a B.S. in Chemical Engineering + +- Succesfully launched [savvi](https://savvi.com) as tech lead and developed the jwt authentication, sign in/out, cart, and checkout features on the application while helping manage other developers working on the project + +- Open source contributions: [added missing rpc method](https://github.com/harmony-one/sdk/pull/82) to harmony-one blockchain's npm package, [json ld transformer](https://github.com/parcel-bundler/parcel/pull/4397) for parcel v2, and extending usage of action-download-artifact to support the [github.ref variable](https://github.com/dawidd6/action-download-artifact/pull/55) +- Published author for [research](https://www.mdpi.com/2571-6182/1/1/1) on the degradation of antibiotics using a plasma apparatus +- 4 years of experience development experience on a wide range of projects, including web applications built using react/angular|.net core|SQL, labview applications for lab experiments, and devops/cloud operations +- 1 year of experience of being tech lead on two successfully launched web projects +- Graduated from Drexel University with a B.S. in Chemical Engineering #### Andre Vanoncini -* Working with the Google Tango tablet for my master thesis (C++, first in depth steps for me with git and linux) -* Developing and implementing a focussing tool and process in C++ with Qt QML GUI -* Getting Inference working with libtorch (C++) and JNI -* Understanding compilation of C++ with cmake and being able to compile on the command line instead of the green play buttons + +- Working with the Google Tango tablet for my master thesis (C++, first in depth steps for me with git and linux) + +- Developing and implementing a focussing tool and process in C++ with Qt QML GUI +- Getting Inference working with libtorch (C++) and JNI +- Understanding compilation of C++ with cmake and being able to compile on the command line instead of the green play buttons #### Fernando Fonseca-Avalos -* Experience with C/C++, Python, JavaScript -* Developing proficiency with Rust. + +- Experience with C/C++, Python, JavaScript + +- Developing proficiency with Rust. #### Mateusz Plaza -* Captain for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. -* 8 years of experience working in high performance medical units -* 2 years of experience leading medical humanitarian teams in Central America -* 2012 Fulbright Research Fellow: completed research project on Poland's Solidarity Movement, exploring methods of self-organization and coordination of social movements that leverage symbols as a form of empowerment and that resist the threat of disinformation/active measures/propaganda. -* Published blockchain researcher, with a focus on the epistemic significance of decentralized blockchain ledgers, especially in terms of Self Sovereign Identity, Decentralized Autonomous Organization, and AI Ontology. + +- Captain for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. + +- 8 years of experience working in high performance medical units +- 2 years of experience leading medical humanitarian teams in Central America +- 2012 Fulbright Research Fellow: completed research project on Poland's Solidarity Movement, exploring methods of self-organization and coordination of social movements that leverage symbols as a form of empowerment and that resist the threat of disinformation/active measures/propaganda. +- Published blockchain researcher, with a focus on the epistemic significance of decentralized blockchain ledgers, especially in terms of Self Sovereign Identity, Decentralized Autonomous Organization, and AI Ontology. #### Jan Eberle -* Experience distinguishing misinformation, disinformation, and combatting the infodemic as a Media Analyst -* Strong communications & usability experience from linguistic studies -* Writing documents for different channels/audiences as a technical writer -* Practical peace keeping experience as a swiss guard in the Vatican + +- Experience distinguishing misinformation, disinformation, and combatting the infodemic as a Media Analyst + +- Strong communications & usability experience from linguistic studies +- Writing documents for different channels/audiences as a technical writer +- Practical peace keeping experience as a swiss guard in the Vatican #### Advisors -* Andrew Plaza -* Zbigniew Zielinski + +- Andrew Plaza + +- Zbigniew Zielinski ### Team Code Repos -* https://github.com/Romulus10 -* https://github.com/isaacadams -* https://github.com/vanandre -* https://github.com/fennelLabs -* https://github.com/Romulus10/infostratus -* https://github.com/Romulus10/blockchain_message -* https://github.com/fennelLabs/Theriak +- https://github.com/Romulus10 +- https://github.com/isaacadams +- https://github.com/vanandre +- https://github.com/fennelLabs +- https://github.com/Romulus10/infostratus +- https://github.com/Romulus10/blockchain_message +- https://github.com/fennelLabs/Theriak ### Team LinkedIn Profiles (if available) -* https://www.linkedin.com/in/seanbatzel/ -* https://www.linkedin.com/in/mateusz-p-6b126424/ -* https://www.linkedin.com/in/jan-eberle-553110195/ -* https://www.linkedin.com/in/fernando-fonseca-avalos-a0a516224/ -* https://www.linkedin.com/in/andreva/ -* https://www.linkedin.com/in/isaacdadams/ +- https://www.linkedin.com/in/seanbatzel/ +- https://www.linkedin.com/in/mateusz-p-6b126424/ +- https://www.linkedin.com/in/jan-eberle-553110195/ +- https://www.linkedin.com/in/fernando-fonseca-avalos-a0a516224/ +- https://www.linkedin.com/in/andreva/ +- https://www.linkedin.com/in/isaacdadams/ ### Ecosystem Fit + Fennel Protocol's key and identity management functionality is fine-tuned for decentralized communication that makes use of pre-defined signals and signs; for example, the Whiteflag specification uses predefined signals and signs derived from International Humanitarian Law, the CRED Disaster Category Classification, and the OECD Economic Infrastructure Common Reporting Standard Codes. Future proposals will build up Fennel Protocol to accomodate the full extent of the Whiteflag Protocol specification. Substrate's interoperability will provide the Polkadot ecosystem with a shared conception of Whiteflag Protocol's predefined signals and signs; -this will allow users to seemlessly send Whiteflag messages across the decentralized Polkadot ecosystem. Critically, an interoperable Whiteflag Network ensures situational awareness is not siloed but is unified in critical use cases. This helps decision makers receive a full picture of the field of operations. +this will allow users to seemlessly send Whiteflag messages across the decentralized Polkadot ecosystem. Critically, an interoperable Whiteflag Network ensures situational awareness is not siloed but is unified in critical use cases. This helps decision makers receive a full picture of the field of operations. #### Whiteflag Section 2.5: Minimally Viable Implementation: -Fennel Protocol will implement the minimally viable implementation of the Whiteflag functionality that allows for the sending of Whiteflag messages. + +Fennel Protocol will implement the minimally viable implementation of the Whiteflag functionality that allows for the sending of Whiteflag messages. We will implement further components of Whiteflag in further proposals. Whiteflag section 2.5 states: any implementation of the Whiteflag Protocol that sends messages on the Whiteflag Network, must implement at a minimum the following functionality: -* The Whiteflag Authentication message with at least one authentication option. At release, both Shared Secret and External Resource Authentication will be fully supported. +- The Whiteflag Authentication message with at least one authentication option. At release, both Shared Secret and External Resource Authentication will be fully supported. -* The possibility to Recall, Update and Discontinue (Whiteflag Reference Codes 1, 2 and 4) any implemented sign or signal, if such Reference Type is valid i.a.w. Reference options. These will be implemented as low-level Fennel messages through the Sign extrinsic call, effectively creating a specialized transaction subtype for each of these. +- The possibility to Recall, Update and Discontinue (Whiteflag Reference Codes 1, 2 and 4) any implemented sign or signal, if such Reference Type is valid i.a.w. Reference options. These will be implemented as low-level Fennel messages through the Sign extrinsic call, effectively creating a specialized transaction subtype for each of these. Fennel Protocol will provide the Substrate infrastructure for two authentication methodologies that abide by Whiteflag Protocol’s specification. -* Method 1, External Resource Authentication: requires the user to declare their identity in some public and trusted place which can be referenced in their activities. This often requires a strong proof, such as a cryptographic signature and public key declaration, that can be verified to prove that a transaction comes from the identity declared. +- Method 1, External Resource Authentication: requires the user to declare their identity in some public and trusted place which can be referenced in their activities. This often requires a strong proof, such as a cryptographic signature and public key declaration, that can be verified to prove that a transaction comes from the identity declared. -* Method 2, Shared Secret Authentication: requires an end user to establish a token known only to themselves and some authentication authority, similar to a password in more Web 2.0-oriented authentication. +- Method 2, Shared Secret Authentication: requires an end user to establish a token known only to themselves and some authentication authority, similar to a password in more Web 2.0-oriented authentication. Fennel Protocol will support both of these authentication mechanisms at launch, with shared secrets covered by our encrypted channel mechanism and external resources declared and submitted as public transactions through the Identity Update extrinsic. @@ -195,15 +210,15 @@ Fennel Protocol will also include support for RSA with a minimal key size of 409 ### Overview -* **Total Estimated Duration:** 3 months -* **Full-Time Equivalent (FTE):** 3 FTE -* **Total Costs:** 50,000 USD +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 50,000 USD ### Milestone 1 — Implement Substrate Modules -* **Estimated duration:** 1 months -* **FTE:** 3 -* **Costs:** 15,000 USD +- **Estimated duration:** 1 months +- **FTE:** 3 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -222,9 +237,9 @@ Fennel Protocol will also include support for RSA with a minimal key size of 409 ### Milestone 2 — Additional features -* **Estimated duration:** 1 months -* **FTE:** 3 -* **Costs:** 15,000 USD +- **Estimated duration:** 1 months +- **FTE:** 3 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -240,9 +255,9 @@ Fennel Protocol will also include support for RSA with a minimal key size of 409 ### Milestone 3 — Additional features -* **Estimated duration:** 1 months -* **FTE:** 3 -* **Costs:** 20,000 USD +- **Estimated duration:** 1 months +- **FTE:** 3 +- **Costs:** 20,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -266,8 +281,8 @@ identity and signaling applications should be able to easily build on the runtim ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** -We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members. +**How did you hear about the Grants Program?** +We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members. Thus far, we've ported our Theriak repository to the most recent version of Substrate as of writing of this application. Financial contribution has not yet begun for the Fennel Protocol project. diff --git a/applications/Gafi.md b/applications/Gafi.md index 984dd2eb01e..af936c5e7c6 100644 --- a/applications/Gafi.md +++ b/applications/Gafi.md @@ -1,7 +1,5 @@ -# W3F Grant Proposal +# Gafi Network - The Network of Game Finance - -- **Project Name:** Gafi Network - The Network of Game Finance - **Team Name:** Cryptoviet - **Gafi Paper:** https://gafi.network/GafiPaper.pdf - **Wiki:** https://wiki.gafi.network/ diff --git a/applications/Gluon_decentralized_hardware_crypto_wallet_services.md b/applications/Gluon_decentralized_hardware_crypto_wallet_services.md index 5ceeb82808e..8e066128187 100644 --- a/applications/Gluon_decentralized_hardware_crypto_wallet_services.md +++ b/applications/Gluon_decentralized_hardware_crypto_wallet_services.md @@ -1,54 +1,54 @@ -# Open Grant Proposal +# Gluon - Decentralized Hardware Crypto Wallet Services > This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/blob/master/README_2.md) on how to submit a proposal. -* **Project Name:** Gluon - Decentralized Hardware Crypto Wallet Services * **Team Name:** TEA Project * **Payment Address:** ERC20(DAI etc.):0x0cE6254832D553590349Ef7a427519d1eb8af70F - > *The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.* -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: + > If this application is in response to an RFP, please indicate this on the first line of this section. ### Overview -Leaking or losing private keys are the primary concerns of most blockchain users. Gluon uses a new approach to prevent such issues. +Leaking or losing private keys are the primary concerns of most blockchain users. Gluon uses a new approach to prevent such issues. -Gluon is a TaaS (Trust-as-a-Service) application that provides hardware crypto wallet services to crypto users. Our main goal is to create an all-in-one private key manager for Polkadot ecosystem blockchains. +Gluon is a TaaS (Trust-as-a-Service) application that provides hardware crypto wallet services to crypto users. Our main goal is to create an all-in-one private key manager for Polkadot ecosystem blockchains. Features: -- Passwordless. Users won't have to take responsibility for backup mnemonic phrases. Social recovery is available for users who have lost all their authentication devices. -- Gluon manages Schnorr Multisig Keys that are randomly distributed and encrypted by hardware-secure-modules (HSM). We call them TEA nodes. -- Users only need to submit a transaction to Gluon, and it will take over the signing and committing to blockchains. -- Leverages popular biometric technologies in mobile devices to attain better user experiences without compromising security. +* Passwordless. Users won't have to take responsibility for backup mnemonic phrases. Social recovery is available for users who have lost all their authentication devices. +* Gluon manages Schnorr Multisig Keys that are randomly distributed and encrypted by hardware-secure-modules (HSM). We call them TEA nodes. +* Users only need to submit a transaction to Gluon, and it will take over the signing and committing to blockchains. +* Leverages popular biometric technologies in mobile devices to attain better user experiences without compromising security. -Gluon is built into a WebAssembly module loaded and ran inside the T-rust framework (they are both TEA projects). Gluon is an application (we call TeaLeaf); T-rust is a framework (TeaTree). T-rust contains layer1 and layer2; Layer1 is a blockchain built using Substrate, while Layer2 is an exceptionally designed mini OS along with WebAssembly modules that run on wasm runtime powered by [WaSCC](https://wascc.dev). Gluon also contains layer1 and layer2. Layer1 is a Substrate pellet running inside Tea Layer1 blockchain, and layer2 is a set of WebAssembly actors running in every TEA node's TeaRuntime. +Gluon is built into a WebAssembly module loaded and ran inside the T-rust framework (they are both TEA projects). Gluon is an application (we call TeaLeaf); T-rust is a framework (TeaTree). T-rust contains layer1 and layer2; Layer1 is a blockchain built using Substrate, while Layer2 is an exceptionally designed mini OS along with WebAssembly modules that run on wasm runtime powered by [WaSCC](https://wascc.dev). Gluon also contains layer1 and layer2. Layer1 is a Substrate pellet running inside Tea Layer1 blockchain, and layer2 is a set of WebAssembly actors running in every TEA node's TeaRuntime. -Gluon serves all Polkadot ecosystem dApps and other blockchains as an entry point (portal); it is transparent to other client chains. There is no integration needed. +Gluon serves all Polkadot ecosystem dApps and other blockchains as an entry point (portal); it is transparent to other client chains. There is no integration needed. We designed and developed Gluon to: -- Lower the barrier to blockchain end-users; improve user experiences. -- Protect users' crypto assets. -- Demonstrate the potential of the Substrate framework and TEA project. +* Lower the barrier to blockchain end-users; improve user experiences. +* Protect users' crypto assets. +* Demonstrate the potential of the Substrate framework and TEA project. >Please provide the following: -> * A brief description of the project. -> * An indication of how you will integrate this project into Substrate / Polkadot / Kusama. -> * An indication of why your team is interested in creating this project. +> +> * A brief description of the project. +> * An indication of how you will integrate this project into Substrate / Polkadot / Kusama. +> * An indication of why your team is interested in creating this project. -### Project Details +### Project Details #### Unique features of Gluon From a users point of view, Gluon works just like a hardware wallet, but with a few differences: -- A traditional hardware wallet is just one single hardware secure module (HSM), but Gluon is a group of potentially thousands of HSM running consensus together to protect clients' assets. (Every TEA Mining Node is an HSM which can be considered as a hardware wallet) -- Users need both a Polkadot extension and a Gluon mobile app to access their Gluon account as 2FA. -- Users can transfer authentication factors from one device to another without backing up and restoring mnemonic phases. -- If users lose both their computer (web auth) and phone (mobile auth), social recovery can still protect and recover their new accounts' crypto assets. -- Users only need to submit a transaction then Gluon will submit the signature to the client blockchain without further user interaction. +* A traditional hardware wallet is just one single hardware secure module (HSM), but Gluon is a group of potentially thousands of HSM running consensus together to protect clients' assets. (Every TEA Mining Node is an HSM which can be considered as a hardware wallet) +* Users need both a Polkadot extension and a Gluon mobile app to access their Gluon account as 2FA. +* Users can transfer authentication factors from one device to another without backing up and restoring mnemonic phases. +* If users lose both their computer (web auth) and phone (mobile auth), social recovery can still protect and recover their new accounts' crypto assets. +* Users only need to submit a transaction then Gluon will submit the signature to the client blockchain without further user interaction. #### Key distribution and protection @@ -56,49 +56,50 @@ From a users point of view, Gluon works just like a hardware wallet, but with a Gluon generates Polkadot accounts for users using the 2-out-of-3 Schnorr Threshold Multsig Algorithm implemented by Schnorrkel. The account public key is aggregated from the 3 key pairs while the private keys are kept by 3 individual parties. They are called P1, P2, and P3. -Among them, P1 is a single sign key stored in the users' mobile phones. Both P2 and P3 are Schnorr multisig keys. Gluon owns P2 for additional security policy control, while Guardians (assigned by the User) owns P3. +Among them, P1 is a single sign key stored in the users' mobile phones. Both P2 and P3 are Schnorr multisig keys. Gluon owns P2 for additional security policy control, while Guardians (assigned by the User) owns P3. P2 is a Schnorr threshold multisig key, which means instead of a single signer, a group of signers control P2. For example, we call them key-pieces such as P2-1, P2-2, P2-3, and so on. They are separately generated and stored by different TEA nodes. Multiple TEA nodes distribute the private key of each signer as the replica. We do not allow a single TEA node to hold more than one key piece of any P2 to prevent any TEA node has enough key-pieces to reach the multisig threshold. This policy also guarantees better distribution of key-pieces over TEA nodes. The signature algorithm is implemented by Schnorrkel too. -P3 is also a Schnorr threshold multisig key but each key-pieces owned by different guardians. Users need to assign their friends or legal entities as guardians. K of n guardians could sign the social recovery transaction to restore a user's account if it lost its P1. This process is called [Social Recovery](https://www.parity.io/social-recovery-on-substrate/). +P3 is also a Schnorr threshold multisig key but each key-pieces owned by different guardians. Users need to assign their friends or legal entities as guardians. K of n guardians could sign the social recovery transaction to restore a user's account if it lost its P1. This process is called [Social Recovery](https://www.parity.io/social-recovery-on-substrate/). -P1 is stored in the users' Gluon mobile app. P1 will never be exposed beyond the phone, even when upgrading devices. However, Gluon doesn't require users to take responsibility to backup mnemonic phrases. When upgrading to a new phone, the Gluon app can transfer P1 securely to the new device without exposing it to the network. If users lose their phones, there is no way to restore P1 because there are no backup mnemonic phrases. Lost or being hacked of P1 does not lead to a loss of assets, as one can use P2+P3 for recovery, and bad actors would need two keys to access crypto assets in the case of a leak. As mentioned above, Gluon can transfer all assets to one's new account by running a social recovery process. +P1 is stored in the users' Gluon mobile app. P1 will never be exposed beyond the phone, even when upgrading devices. However, Gluon doesn't require users to take responsibility to backup mnemonic phrases. When upgrading to a new phone, the Gluon app can transfer P1 securely to the new device without exposing it to the network. If users lose their phones, there is no way to restore P1 because there are no backup mnemonic phrases. Lost or being hacked of P1 does not lead to a loss of assets, as one can use P2+P3 for recovery, and bad actors would need two keys to access crypto assets in the case of a leak. As mentioned above, Gluon can transfer all assets to one's new account by running a social recovery process. #### Hardware Secure Module -TEA nodes are HSM (Hardware Secure Module). One can consider commonly used hardware wallets as special-purpose HSM, but TEA nodes are a general-purpose HSM that can do much more. The secret will never be exposed outside of hardware-protected TEA node's RAM nor saved to any storage media persistently. When transferring secrets between TEA nodes (for example, distributing replica), every TEA nodes will run Remote Attestation before an end to end encryption and send. When using P2 co-signing a transaction, the TEA Node will query the layer1 blockchain to verify the signing conditions first and then sign the transaction inside HSM. No secret leaves the HSM except the digital signature. Each co-signer sign using its holding key-piece to a signature-piece. These signature-pieces get aggregated in layer-1 blockchain to become a single signature. As long as the number of co-signers reaches the threshold, this signature can pass verification by Polkadot. +TEA nodes are HSM (Hardware Secure Module). One can consider commonly used hardware wallets as special-purpose HSM, but TEA nodes are a general-purpose HSM that can do much more. The secret will never be exposed outside of hardware-protected TEA node's RAM nor saved to any storage media persistently. When transferring secrets between TEA nodes (for example, distributing replica), every TEA nodes will run Remote Attestation before an end to end encryption and send. When using P2 co-signing a transaction, the TEA Node will query the layer1 blockchain to verify the signing conditions first and then sign the transaction inside HSM. No secret leaves the HSM except the digital signature. Each co-signer sign using its holding key-piece to a signature-piece. These signature-pieces get aggregated in layer-1 blockchain to become a single signature. As long as the number of co-signers reaches the threshold, this signature can pass verification by Polkadot. #### Access control logic -Polkadot allows unlocking User's DOT based on 2 of 3 mutisig from P1 P2 and P3. Gluon has no control over P1 (owned by the User) and P3 (owned by the User's friend - guardians). If a user no longer trusts Gluon, it can ask its guardians to sign P3 along with its P1, and the User still has full control over its assets. If a user lost its P1, it could create a new P1 then recover its assets by running the social recovery process by P2 and P3. If a user wants to update its guardians' list, it can create a new P3 since P1 and P2 are available. +Polkadot allows unlocking User's DOT based on 2 of 3 mutisig from P1 P2 and P3. Gluon has no control over P1 (owned by the User) and P3 (owned by the User's friend - guardians). If a user no longer trusts Gluon, it can ask its guardians to sign P3 along with its P1, and the User still has full control over its assets. If a user lost its P1, it could create a new P1 then recover its assets by running the social recovery process by P2 and P3. If a user wants to update its guardians' list, it can create a new P3 since P1 and P2 are available. P1 is stored in users' mobile apps. Gluon mobile app uses general mobile security protections to protect P1. Such as Biometric ID, Symmetric encryption (6 digits user input passcode), Hardware security chip for some particular model when available. P1 along won't be more secure than other modern crypto wallet mobile apps. That's why we have additional P2 and P3 to protect the User's crypto assets. -P2 is the only key owned by Gluon. When a user requests to sign a transaction, each TEA node that holds a key-piece will run authentication logic separately. The authentication logic includes +P2 is the only key owned by Gluon. When a user requests to sign a transaction, each TEA node that holds a key-piece will run authentication logic separately. The authentication logic includes -- Verifying web and mobile 2FA. The User has to submit a signing request using both the Polkadot browser extension and Gluon mobile app. -- For spending transactions, verify the daily limit or other constraints set by the User in layer1. For example, when the User claims loss of P1 and sets its assets in the Social Recovery frozen period, Gluon will suspend the request. -- For social recovery transactions, verify the guardians' signature follow the predefined logic. For example, suppose a user lost both their computer and mobile phone (all 2FA). In that case, additional requirements apply to social recovery processes such as time window, sequence, or geolocation to mitigate phishing attacks. +* Verifying web and mobile 2FA. The User has to submit a signing request using both the Polkadot browser extension and Gluon mobile app. +* For spending transactions, verify the daily limit or other constraints set by the User in layer1. For example, when the User claims loss of P1 and sets its assets in the Social Recovery frozen period, Gluon will suspend the request. +* For social recovery transactions, verify the guardians' signature follow the predefined logic. For example, suppose a user lost both their computer and mobile phone (all 2FA). In that case, additional requirements apply to social recovery processes such as time window, sequence, or geolocation to mitigate phishing attacks. -Given such logic run on the Gluon Pellet (on-chain) and Gluon Wasm Actors (off-chain), in the future, we can easily add more complex logic without on-chain limitations. +Given such logic run on the Gluon Pellet (on-chain) and Gluon Wasm Actors (off-chain), in the future, we can easily add more complex logic without on-chain limitations. -P3 is only used for Social Recovery. Because of Schnorr Mutisig Algorithm, the guardians' list never exposes in the clear on the blockchain. Even the guardians themself won't know they are selected guardians or know other guardians in the same group. There is little chance for guardians to collude and sign P3 without the User's permission. +P3 is only used for Social Recovery. Because of Schnorr Mutisig Algorithm, the guardians' list never exposes in the clear on the blockchain. Even the guardians themself won't know they are selected guardians or know other guardians in the same group. There is little chance for guardians to collude and sign P3 without the User's permission. #### User experiences -From the end user's point of view, Gluon is a mobile app and a web extension. The end-user needs to install the Polkadot web extension on their browser to visit any dApp sites to generate transactions to be signed. They also will need to install a Gluon mobile app as a decentralized 2FA (not the traditional centralized 2FA). +From the end user's point of view, Gluon is a mobile app and a web extension. The end-user needs to install the Polkadot web extension on their browser to visit any dApp sites to generate transactions to be signed. They also will need to install a Gluon mobile app as a decentralized 2FA (not the traditional centralized 2FA). -Users can go to the Gluonwallet.com website or any other compatible dApp to create a transaction. The web extension will generate a transaction like a QR code on the web page. Users will use the Gluon mobile app to scan this QR code, verify the transaction details, then fingerprint-unlock the partial signing on the phone. Once the phone sends the partial signature to the Gluon network, TEA nodes will multisign the same tx using P2. Once two partial signatures are complete, they are aggregated and committed to the client blockchain to continue processing the transaction. +Users can go to the Gluonwallet.com website or any other compatible dApp to create a transaction. The web extension will generate a transaction like a QR code on the web page. Users will use the Gluon mobile app to scan this QR code, verify the transaction details, then fingerprint-unlock the partial signing on the phone. Once the phone sends the partial signature to the Gluon network, TEA nodes will multisign the same tx using P2. Once two partial signatures are complete, they are aggregated and committed to the client blockchain to continue processing the transaction. #### Relationship between Gluon and T-rust -From the miners' point of view, Gluon is a dApp that runs on top of the T-rust framework. When compiling the source code, a WebAssembly file "gluon.wasm" is generated. This wasm file is loaded to the miner's TEA node by adding Gluon.wasm file hash to their TEA nodes' manifest file. Miners can load this wasm module from IPFS directly. Once "gluon.wasm" is loaded into TEA runtime, this TEA node becomes a TEA hardware wallet capability provider. +From the miners' point of view, Gluon is a dApp that runs on top of the T-rust framework. When compiling the source code, a WebAssembly file "gluon.wasm" is generated. This wasm file is loaded to the miner's TEA node by adding Gluon.wasm file hash to their TEA nodes' manifest file. Miners can load this wasm module from IPFS directly. Once "gluon.wasm" is loaded into TEA runtime, this TEA node becomes a TEA hardware wallet capability provider. Gluon.wasm only handles crypto wallet related logic. All other consensuses, security, network, and hardware validation happens in the T-rust framework. ![relationship tea](https://cdn-images-1.medium.com/max/1120/1*2O7WDwTwH4DlIr4zbOMxng.png) #### Gluon and T-rust's root of trust and PoT (Proof of Trust) consensus + T-rust is a layer2 trusted computing solution on top of a Substrate-based blockchain (layer1). Unlike most blockchain, whose root-of-trust comes from cryptography and consensus, T-rust introduces hardware root-of-trust as the third dimension. Unlike most other blockchains that make consensus on the result, T-rust makes consensus on the proof of trust that comes from hardware TPM chips. Using hardware RoT makes the consensus much more efficient than many blockchains. T-rust can run complex or privacy-sensitive computations, which are not likely possible in other blockchains. Distributed storage of private keys needs both privacy and complex computing, so Gluon is an ideal dApp running on top of T-rust. Gluon and T-rust are two TEA Projects. ![root of trust](https://cdn-images-1.medium.com/max/1120/1*5cLoCE4mLRw7hhDjcuaAxA.png) @@ -108,23 +109,22 @@ T-rust is a layer2 trusted computing solution on top of a Substrate-based blockc There is nothing that needs to be done for other blockchains when integrating with Gluon as long as the client blockchain supports Schnorr Multisig. Gluon is transparent to other client blockchains. Gluon is virtually a client who commits the signed transaction and listens to block events. Polkadot will support off-line Schnorr Multisig very soon. For other dApps, integrating with Gluon is as simple as adding one js API. This js API does three things: -- Gathering input transaction details and show in a QR code. Prompt the User to scan this QR code using Gluon mobile app. -- Sending the hash of transaction and client_id in a TEA transaction to the TEA blockchain. - +* Gathering input transaction details and show in a QR code. Prompt the User to scan this QR code using Gluon mobile app. +* Sending the hash of transaction and client_id in a TEA transaction to the TEA blockchain. #### UI mockups ![typical workflow](https://github.com/tearust/gluon-docs/blob/master/res/typical-workflow.png?raw=true) -The diagram above shows a typical UI workflow, which is signing a DOT spending transaction. +The diagram above shows a typical UI workflow, which is signing a DOT spending transaction. -Users start a task from the web browser. It could be the Gluon web portal or any dApps' website embedded with our js API. A hash of the transaction detail is sent to Gluon TeaLeaf. A QR code is shown on the web page for the paired Gluon mobile app to scan. +Users start a task from the web browser. It could be the Gluon web portal or any dApps' website embedded with our js API. A hash of the transaction detail is sent to Gluon TeaLeaf. A QR code is shown on the web page for the paired Gluon mobile app to scan. After scanning the QR code, the Gluon mobile app shows the transaction's detail for users to confirm visually. Users approve this transaction by fingerprinting and six digits wallet passcode. Gluon mobile app partially signs the transaction using P1. Both the signature and transaction details are sent to Gluon TeaLeaf to continue. -Gluon TeaLeaf takes over the rest of the task by verifying and signing using P2. Finally, Gluon TeaLeaf sends the signature by P1 and P2 to Polkadot to complete the transaction. +Gluon TeaLeaf takes over the rest of the task by verifying and signing using P2. Finally, Gluon TeaLeaf sends the signature by P1 and P2 to Polkadot to complete the transaction. The User will receive the confirmation event of a completed task. @@ -137,20 +137,20 @@ T-rust is a bit more complicated. ##### TEA's four pillars ![four pillars](https://github.com/tearust/tea-docs/raw/main/res/s8.jpg) -In general, TEA is based on four technologies: -- Substrate: This is layer 1 of T-rust. The blockchain runs consensus on Proof-of-Trust, and immutably stores, processes, and verifies PoT (the hashes from the hardware chips). -- IPFS: This is the file system and network layer of T-rust. All public code and data are stored in IPFS, but all secrets are kept inside TEA modules (the HSM). -- Trusted Computing: This is where the hardware root of trust comes from. We use the TPM chips inside the TEA module (HSM) to generate Proof of Trust. -- WebAssembly: All running executable code is in wasm format and runs inside secure wasm runtime except for our OS, runtime, and system providers. +In general, TEA is based on four technologies: +* Substrate: This is layer 1 of T-rust. The blockchain runs consensus on Proof-of-Trust, and immutably stores, processes, and verifies PoT (the hashes from the hardware chips). +* IPFS: This is the file system and network layer of T-rust. All public code and data are stored in IPFS, but all secrets are kept inside TEA modules (the HSM). +* Trusted Computing: This is where the hardware root of trust comes from. We use the TPM chips inside the TEA module (HSM) to generate Proof of Trust. +* WebAssembly: All running executable code is in wasm format and runs inside secure wasm runtime except for our OS, runtime, and system providers. -90% of the source code is written in Rust. The other 6% is written in JS and the remaining 4% in Golang. +90% of the source code is written in Rust. The other 6% is written in JS and the remaining 4% in Golang. For more detail on the TEA project and T-rust framework, you may visit teaproject.org. #### Prior works and demo Gluon is a dApp and a wasm module running on top of T-rust. We currently do not have the Gluon demo running (but it will be available soon). We do have another demo app showing the capability of the T-rust framework. -This demo is a Tensorflow image recognization running on Substrate blockchain. +This demo is a Tensorflow image recognization running on Substrate blockchain. Here is the video link: > Click to play the demo video @@ -162,89 +162,100 @@ Here's another video introduction to the TEA project: [![](https://github.com/tearust/tea-docs/raw/main/res/blog/WX20201215-115720@2x.png)](http://www.youtube.com/watch?v=-NgR3ySWwXg "") > Therefore, we ask the teams to submit (where relevant): +> > * Mockups/designs of any UI components > * API specifications of the core functionality > * An overview of the technology stack to be used > * Documentation of core components, protocols, architecture, etc. to be deployed > * PoC/MVP or other relevant prior work or research on the topic +### Ecosystem Fit -### Ecosystem Fit Are there any other projects similar to yours? If so, how is your project different? There are many existing crypto wallets in the market. They either store the private keys on client devices (phone, hardware wallet) or centralized servers. There are quite a few wallets in Web3 applications. For example: [bdwallet](https://github.com/tearust/Open-Grants-Program/blob/master/applications/bdwallet.md), or [subwallet](https://github.com/tearust/Open-Grants-Program/blob/master/applications/subwallet.md) -Gluon has a very decentralized approach. We do not store the original keys anywhere. Instead, we use the TEA project's decentralized trusted computing infrastructure to scramble, store, and multisign. This approach prevents users from losing or leaking their keys. +Gluon has a very decentralized approach. We do not store the original keys anywhere. Instead, we use the TEA project's decentralized trusted computing infrastructure to scramble, store, and multisign. This approach prevents users from losing or leaking their keys. A few crypto wallets outside of the Polkadot ecosystem are a little bit similar to ours. [ZenGo](https://zengo.com/security/) provides "passwordless" but still require centralized servers to store encrypted secrets. We do everything decentralized. -[Recovery pellets](https://github.com/paritytech/substrate/tree/master/frame/recovery) is not a wallet but a Substrate pellet with the social recovery idea. We did not know it until we search for a similar project just now. +[Recovery pellets](https://github.com/paritytech/substrate/tree/master/frame/recovery) is not a wallet but a Substrate pellet with the social recovery idea. We did not know it until we search for a similar project just now. [Ledger](https://www.ledger.com/) or [Trezor](https://trezor.io/) are hardware wallets. We do not sell hardware wallet units to end-users. We provide Trust-as-a-Service instead. ## Team :busts_in_silhouette: ### Team members + * Name of the team leader: Kevin Zhang -* Names of team members: +* Names of team members: + - William Zhang -- Jacky Li -- Raindust Yan -- Zehua Jiang -- Lex Pablo +* Jacky Li +* Raindust Yan +* Zehua Jiang +* Lex Pablo ### Contact + * **Contact Name:** Kevin G. Zhang * **Contact Email:** kevin.zhang.canada@gmail.com * **Web site:** teaproject.org gluonwallet.com -### Legal Structure +### Legal Structure + * **Registered Address:** 4006 Hastings Park Ct, San Jose, CA 95136 U.S.A. * **Registered Legal Entity:** Elk Insight LLC. ### Team's experience + Please describe the team's relevant experience. If the project involves development work, we'd appreciated if you can single out a few interesting code commits made by team members on their past projects. For research-related grants, references to past publications and projects in a related domain are helpful. -The TEA-Project started in the year 2019. The idea originally came to the team leader, Kevin Zhang, seven years ago when working as the CTO of iHealthLabs. Utilizing patients' health data for scientific research while preventing health data breaches has always been a major problem. He initially tried to solve the dilemma using blockchain but realized that the existing blockchain technologies were far too slow to be practical. He then decided to add the root of trust alongside existing blockchain cryptography + consensus. This is the hardware root of trust. TEA uses existing mature Trusted Computing technologies to provide secure computing services to client blockchains without requiring specialized CPU features such as Phala's (TEE) Intel SGX CPU or Bitcoin's ASIC CPU. Besides the Tensorflow demo app on TEA, making a practical crypto wallet can demonstrate how TEA can do better, so they started the Gluon. The full story of the project can be found here: [Sweeping Monk Medium Blog] (https://pushbar.medium.com/0-of-n-cover-letter-of-the-trusted-webassembly-runtime-on-ipfs-12a4fd8c4338) +The TEA-Project started in the year 2019. The idea originally came to the team leader, Kevin Zhang, seven years ago when working as the CTO of iHealthLabs. Utilizing patients' health data for scientific research while preventing health data breaches has always been a major problem. He initially tried to solve the dilemma using blockchain but realized that the existing blockchain technologies were far too slow to be practical. He then decided to add the root of trust alongside existing blockchain cryptography + consensus. This is the hardware root of trust. TEA uses existing mature Trusted Computing technologies to provide secure computing services to client blockchains without requiring specialized CPU features such as Phala's (TEE) Intel SGX CPU or Bitcoin's ASIC CPU. Besides the Tensorflow demo app on TEA, making a practical crypto wallet can demonstrate how TEA can do better, so they started the Gluon. The full story of the project can be found here: [Sweeping Monk Medium Blog] () ### Team Code Repos -* https://github.com/tearust/Gluon_Actor -* https://github.com/tearust/Gluon_Pellet -* https://github.com/tearust/gluon-docs -* https://github.com/tearust/tea-docs + +* +* +* +* ### Team LinkedIn Profiles -* https://www.linkedin.com/in/kevingzhang/ -* https://www.linkedin.com/in/zhijun/ -* https://www.linkedin.com/in/jacky-li-4039747b/ -* https://www.linkedin.com/in/mingzhi-yan-7544b9203/ -* https://www.linkedin.com/in/zehua-jiang-7494a8203/ -* https://www.linkedin.com/in/lex-pablo-a638941ba/ -## Development Roadmap :nut_and_bolt: +* +* +* +* +* +* + +## Development Roadmap :nut_and_bolt: > This section should break out the development roadmap into several milestones. Since the milestones will appear in the grant contract, it helps to describe the functionality we should expect, plus how we can check that such functionality exists in the product. Whenever milestones are delivered, we refer to the contract to ensure that everything has been delivered as expected. -Below, we provided an **example roadmap**. In the descriptions, it should be clear how the project is related to Substrate and/or Polkadot. We recommend to fit the scope of the work within a 3 month period and for teams to structure their roadmap as 1 month = 1 milestone. +Below, we provided an **example roadmap**. In the descriptions, it should be clear how the project is related to Substrate and/or Polkadot. We recommend to fit the scope of the work within a 3 month period and for teams to structure their roadmap as 1 month = 1 milestone. For each milestone: + * Please be sure to include a specification of your software. Treat it as a contract - the level of detail must be enough to later verify that the software meets the specification. To assist you in defining it, we created a document with examples for some grant categories [here](../src/grant_guidelines_per_category.md). * Please include the total amount of funding requested per milestone. * Please note that we require documentation (e.g. tutorials, API specifications, architecture details) in each milestone. This ensures that the code can be widely used by the community. * Please provide a test suite, comprising unit and integration tests, along with a guide on how to run these. -* Please commit to providing a dockerfiles for the delivery of your project. +* Please commit to providing a dockerfiles for the delivery of your project. * Please indicate the milestone duration, as well as a number of Full-Time Employees working on each milestone, and include the number of days along with their cost per day. * Deliverables 0a-0d are mandatory and should not be removed, unless you explicitly specify a reason within the PR's `Additional Notes` section (e.g. Milestone X is research-oriented and as such there is no code to test) ### Overview + * **Total Estimated Duration:** 5 months * **Full-time equivalent (FTE):** 2.5 FTE * **Total Costs:** 28k USD ### Milestone 1 Example — Web app and mobile app pairing + * **Estimated Duration:** 4 Weeks * **FTE:** 2.5 FTE * **Costs:** 5.6k USD @@ -268,6 +279,7 @@ To assist you in defining it, we created a document with examples for some grant | 3.1 | Gluon substrate pellet: Search API | Search user public information | ### Milestone 2 - Phone upgrading and social recovery + * **Estimated Duration:** 4 Weeks * **FTE** 2.5 FTE * **Cost:** 5.6k USD @@ -288,13 +300,14 @@ To assist you in defining it, we created a document with examples for some grant | 4.1 | Layer1 | Suspend old account activity during the recovering process | | 4.2 | Gluon TeaLeaf | Generate a new account to accept assets | | 5.0 | Layer1 | Verify all social recovery confirmation, transfer assets to new account | - + ### Milestone 3 - Generate DOT asset on test net + * **Estimated Duration:** 4 Weeks * **FTE:** 2.5 FTE * **Costs:** 5.6k USD -Prerequisites: -This milestone require Schnorrkel threshold signature issue https://github.com/w3f/schnorrkel/issues/11 completes. +Prerequisites: +This milestone require Schnorrkel threshold signature issue completes. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -314,10 +327,11 @@ This milestone require Schnorrkel threshold signature issue https://github.com/w | 4.1 | Gluon TeaLeaf | Executor aggregates public key from initial pinners | | 4.2 | Gluon TeaLeaf | Delegator verify and response to Layer 1 | | 4.3 | Gluon TeaLeaf | Suspend old P2 P3 when a social recovery task in progress| -| 5.0 | Layer1 | Create Schnorr multisig test chain | +| 5.0 | Layer1 | Create Schnorr multisig test chain | | 5.1 | Layer1 | Update user assets | ### Milestone 4 - Sign DOT transaction on testnet + * **Estimated Duration:** 4 Weeks * **FTE** 2.5 FTE * **Cost:** 5.6k USD @@ -337,8 +351,9 @@ This milestone require Schnorrkel threshold signature issue https://github.com/w | 4.0 | Gluon TeaLeaf | Executor find pinners and organize them to multisign tx individually | | 4.1 | Gluon TeaLeaf | Executor verify and aggregates signatures. Send the P2 signatures to test net | | 5.0 | Layer 1 | Settle payment distribution | - + ### Milestone 5 - Migrate to real hardware and test on Polkadot + * **Estimated Duration:** 4 Weeks * **FTE** 2.5 FTE * **Cost:** 5.6k USD @@ -359,13 +374,13 @@ This milestone require Schnorrkel threshold signature issue https://github.com/w Gluon will be a full-featured demo application for the TEA project once it is ready. So far, there are a few limitations that we are working on. -- Integrate with [Parsec](https://github.com/parallaxsecond/parsec). Parsec can be an abstract layer between TeaRuntime and security-related hardware. It makes TEA agnostic to different hardware platforms. It may increase the adaption of TEA. - - Besides DOT, we will all Polkadot ecosystem chains and other Schnorr signature compatible chains. - - We will retire our facade interface service and use off-chain workers instead. - - Besides hardware protection and Schnorr Multisig algorithm, we open eyes to SMPC and FHE algorithm such as BLS Signature Scheme. +* Integrate with [Parsec](https://github.com/parallaxsecond/parsec). Parsec can be an abstract layer between TeaRuntime and security-related hardware. It makes TEA agnostic to different hardware platforms. It may increase the adaption of TEA. +* Besides DOT, we will all Polkadot ecosystem chains and other Schnorr signature compatible chains. +* We will retire our facade interface service and use off-chain workers instead. +* Besides hardware protection and Schnorr Multisig algorithm, we open eyes to SMPC and FHE algorithm such as BLS Signature Scheme. Most items in this to-do list are part of the TEA Project plan. When TEA is ready, most of the features will be available too. ## Additional Information :heavy_plus_sign: -We started the TEA project in 2019. It has been under the radar until recently when it was released to the public. We believe the TEA project could grow large and become the backend service platform for a new type of dApps. These dApps can go beyond the limit of traditional blockchain technologies. Gluon is just one of the many possible demo apps. Once our honor gets granted, we will start looking for investors and hire a CEO and more developers to join us. We hope to maintain a long term and close relationship with the Polkadot community. +We started the TEA project in 2019. It has been under the radar until recently when it was released to the public. We believe the TEA project could grow large and become the backend service platform for a new type of dApps. These dApps can go beyond the limit of traditional blockchain technologies. Gluon is just one of the many possible demo apps. Once our honor gets granted, we will start looking for investors and hire a CEO and more developers to join us. We hope to maintain a long term and close relationship with the Polkadot community. diff --git a/applications/GreenLemon.md b/applications/GreenLemon.md index 5cc6b98d609..0ae0a06399a 100644 --- a/applications/GreenLemon.md +++ b/applications/GreenLemon.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Green Lemon -- **Project Name:** Green Lemon - **Team Name:** Green Lemon - **Payment Address:** 0xf4f463B9A0ADa68536423121e7Bf9E559ce54fAf(Ethereum ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Idavoll Network.md b/applications/Idavoll Network.md index a2610174b1a..f541b4a67bb 100644 --- a/applications/Idavoll Network.md +++ b/applications/Idavoll Network.md @@ -1,10 +1,9 @@ -# Open Grant Proposal +# Idavoll Network -* Project: Idavoll Network * Proposer: [jasonberger0](https://github.com/jasonberger0) * Payment Address: 1NNtuqwroKc9cMZdigpLdNLrzPKCp7zkXT -## Project Overview : +## Project Overview ### Overview @@ -22,30 +21,29 @@ Idavoll Network has a set of pallets to achive the management of DAOs: orgnaizat #### Transfer Assets -+ the Organization members initiate a proposal to transfer organizational assets through the Finance Module. The proposal is confirmed on the Vote Module and required to complete the voting results of the organization members within a certain period of time. The voting results are required to meet the asset transfer rules in the Finance Module. The approval votes are greater than the minimum approval votes. Only after the number and the number of negative votes are less than the limit of the maximum number of negative votes, can the proposed movement of asset transfer within the organization be realized through the Finance Module. +* the Organization members initiate a proposal to transfer organizational assets through the Finance Module. The proposal is confirmed on the Vote Module and required to complete the voting results of the organization members within a certain period of time. The voting results are required to meet the asset transfer rules in the Finance Module. The approval votes are greater than the minimum approval votes. Only after the number and the number of negative votes are less than the limit of the maximum number of negative votes, can the proposed movement of asset transfer within the organization be realized through the Finance Module. #### Snapshot Vote Decisions -+ We can combine the organization module, voting module and token module to implement the decision management process. Users can create any proposal (an easy-to-understand term that the proposal must follow) and initiate the voting process. All users holding the corresponding tokens can participate in the voting. The voting ends, the Idavoll Network will count the voting results of the voters according to the snapshot of the current blockchain state. The voting results will be used as a community consensus and will be permanently stored on the blockchain. +* We can combine the organization module, voting module and token module to implement the decision management process. Users can create any proposal (an easy-to-understand term that the proposal must follow) and initiate the voting process. All users holding the corresponding tokens can participate in the voting. The voting ends, the Idavoll Network will count the voting results of the voters according to the snapshot of the current blockchain state. The voting results will be used as a community consensus and will be permanently stored on the blockchain. ## Team :busts_in_silhouette: ### Team members -+ jasonberger0 -+ Dylan -+ kericfrank +* jasonberger0 +* Dylan +* kericfrank ### Team’s experience -+ jasonberger0 Over 10 years of experiences in Development and Management,real time database products and digital currency transaction platform products expert. Currently focused on Blockchain Development and Cross-chain Technologies. -+ Dylan holds a master degree from Tsinghua University. He has more than 10 years of experience inlarge-scale computing and algorithm, with many patents such as consensus algorithm and blockchain transaction. -+ kericfrank: 8+ years development experience, proficient in public chain and cross chain development, proficient in using go and rust, p2p network expert. - +* jasonberger0 Over 10 years of experiences in Development and Management,real time database products and digital currency transaction platform products expert. Currently focused on Blockchain Development and Cross-chain Technologies. +* Dylan holds a master degree from Tsinghua University. He has more than 10 years of experience inlarge-scale computing and algorithm, with many patents such as consensus algorithm and blockchain transaction. +* kericfrank: 8+ years development experience, proficient in public chain and cross chain development, proficient in using go and rust, p2p network expert. ### Team Code Repos -* https://github.com/idavollnetwork +* ## Development Roadmap :nut_and_bolt: @@ -75,6 +73,6 @@ In this milestone, We will implement Idavoll DAO proof-of-concept. ## Future Plans -+ we will provides a Dapp for everyone to interact with the Idovall network. +* we will provides a Dapp for everyone to interact with the Idovall network. -+ In the future, the Idavoll Network will add a court protocol to resolve subjective disputes with binary outcomes, combined with the use of IDV’s infrastructure, so that the DAOs can create proposal agreements that define the subjective constraints of organizational operations, and can be used by a minority of interests Stakeholder implementation. \ No newline at end of file +* In the future, the Idavoll Network will add a court protocol to resolve subjective disputes with binary outcomes, combined with the use of IDV’s infrastructure, so that the DAOs can create proposal agreements that define the subjective constraints of organizational operations, and can be used by a minority of interests Stakeholder implementation. diff --git a/applications/Integrating-ISO8583.md b/applications/Integrating-ISO8583.md index 16fc3066453..90b20d819d4 100644 --- a/applications/Integrating-ISO8583.md +++ b/applications/Integrating-ISO8583.md @@ -1,10 +1,9 @@ -# W3F Grant Proposal +# Integrating ISO-8583 > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. > > See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. -- **Project Name:** Integrating ISO-8583 - **Team Name:** Stardust Labs Inc. - **Payment Address:** 0xF3d5F194D9eF961a85a4d5be05EFda7B2B33005d (DAI, Ethereum Mainet) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 @@ -25,28 +24,29 @@ Supporting international standards would smooth the connection between crypto an - An indication of why your team is interested in creating this project. -I've built credit card infrastructure before during my role as an analyst at Capital One and believe I can bring some experience from traditional finance to this problem. At the very least I can call out the details and complex logistics that others without might miss. +I've built credit card infrastructure before during my role as an analyst at Capital One and believe I can bring some experience from traditional finance to this problem. At the very least I can call out the details and complex logistics that others without might miss. ### Project Details [ISO-8583](https://en.wikipedia.org/wiki/ISO_8583) is the international standard for card based payments and transactions. It's used everywhere from ATMs to Merchant point of sale terminals. Supporting international standards could help smooth the connection between crypto and traditional financial institutions. [Further simplifying matters is](https://crates.io/crates/iso8583) [that several rust crates exist](https://github.com/rkbalgi/iso8583_rs) [supporting the packing and unpacking of ISO-8583 data streams.](https://docs.rs/i8583/latest/i8583/) At first glance, it seems like one could easily just integrate these packages to achieve the goals of the RFP, namely: + - (Java) APIs or packages that make it possible for the traditional finance industry to integrate a substrate-based ISO 8583 solution into their existing tech stack. - Proof of concepts, potentially leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/v3/concepts/off-chain-features/) that show the advantages of using ISO 8583 together with Substrate. -- Efficient on-chain representation of the ISO 8583 syntax +- Efficient on-chain representation of the ISO 8583 syntax Unfortunately, the logistics of actually implementing ISO-8583 compliant infrastructure on blockchains is unintuitvely complex. At a minimum, 3 major issues exist that must be addressed. **Security** -ISO-8583 datastreams [reveal far too much information to ever be publically exposed](https://neapay.com/post/iso8583-atm-pos-crypto-api-integration-coinbase-binance_102.html). Here neapay proposes using ISO-8583 to connect to Coinbase to purchase crypto. However you can see that once the datastream is unpacked, the user's financial details are immediately revealed. Unpacking data is a trivial process that has no security, ISO-8583 data is not encrypted. Of note is the exposed primary account number (F02_PAN: 9876 5000 0030 6082). Most people would recognize this number faster as their credit card number. While it is possible, and implemented in practice, to transfer the data securely between two, trusted centralized servers using [Diffie Hellman key exchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), research is needed to construct a way to place ISO-8583 data on-chain securely, if it is even possible. There are also laws about retaining this information for a fixed period of time, for example, [Minnesota, a US state mandates that this information is deleted within 48 hours of reciept](https://www.revisor.mn.gov/statutes/cite/325E.64) which is at odds with the enduring, provable structure of a blockchain. +ISO-8583 datastreams [reveal far too much information to ever be publically exposed](https://neapay.com/post/iso8583-atm-pos-crypto-api-integration-coinbase-binance_102.html). Here neapay proposes using ISO-8583 to connect to Coinbase to purchase crypto. However you can see that once the datastream is unpacked, the user's financial details are immediately revealed. Unpacking data is a trivial process that has no security, ISO-8583 data is not encrypted. Of note is the exposed primary account number (F02_PAN: 9876 5000 0030 6082). Most people would recognize this number faster as their credit card number. While it is possible, and implemented in practice, to transfer the data securely between two, trusted centralized servers using [Diffie Hellman key exchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), research is needed to construct a way to place ISO-8583 data on-chain securely, if it is even possible. There are also laws about retaining this information for a fixed period of time, for example, [Minnesota, a US state mandates that this information is deleted within 48 hours of reciept](https://www.revisor.mn.gov/statutes/cite/325E.64) which is at odds with the enduring, provable structure of a blockchain. **Transaction Reversals** -Outside of simple purchases, one of the most common messages communicated over ISO-8583 are [chargebacks.](https://en.wikipedia.org/wiki/Chargeback) [About 0.6% of all transactions are ultimately recalled, though it varies by industry.](https://shiftprocessing.com/chargeback-statistics/) ISO-8583 was designed to handle this process seamlessly and has a reserved MTI code for all chargebacks and reversals (x4xx). Unfortunately, modern blockchains by design are irreversible. From the original [introduction of Satoshi Nakamoto's white paper](https://bitcoin.org/bitcoin.pdf). +Outside of simple purchases, one of the most common messages communicated over ISO-8583 are [chargebacks.](https://en.wikipedia.org/wiki/Chargeback) [About 0.6% of all transactions are ultimately recalled, though it varies by industry.](https://shiftprocessing.com/chargeback-statistics/) ISO-8583 was designed to handle this process seamlessly and has a reserved MTI code for all chargebacks and reversals (x4xx). Unfortunately, modern blockchains by design are irreversible. From the original [introduction of Satoshi Nakamoto's white paper](https://bitcoin.org/bitcoin.pdf). > While the system (traditional finance) works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. Supporting ISO-8583 functionality would require building a new token standard, or making changes to the operation of the blockchain to allow reversible transactions. A solution highlighted in the original bitcoin white paper is automatic escrow accounts, but research would be needed to identify the best way to implement these accounts or if there are better solutions. - + **Authorizations and Privilages** This leads to another major challenge. In traditional banking, the users are not equal. Certain entites such as the issuing bank or network can make decisions unilaterally without recourse. An example of this would be the aforementioned chargeback or transaction reversals which can be performed by the issuing bank or network for any reason. Blockchains operate on an equivalent peer model, and it is an open question as to how to authorize a super user and who should maintain super user priviliages over the entire network. @@ -66,7 +66,7 @@ Supporting international standards would smooth the connection between crypto an - **Contact Name:** Adit Patel - **Contact Email:** adit.patel@stardustfunds.com -- **Website:** https://stardust.finance/ +- **Website:** ### Legal Structure @@ -78,15 +78,15 @@ Adit is a technical expert on cryptography, distributed ledgers, financial marke ### Team Code Repos -- https://github.com/adit313/ +- ### Team LinkedIn Profiles (if available) -- https://www.linkedin.com/in/adit-patel/ +- ## Development Status :open_book: -- link to RFP: https://github.com/w3f/Grants-Program/blob/master/rfps/open/ISO_8583.md +- link to RFP: ## Development Roadmap :nut_and_bolt: diff --git a/applications/Interstellar-Network.md b/applications/Interstellar-Network.md index f1a0f0c9a7f..4e59242e617 100644 --- a/applications/Interstellar-Network.md +++ b/applications/Interstellar-Network.md @@ -1,81 +1,61 @@ -# W3F Grant Proposal - +# Interstellar - Wallet Phase 1 > > See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. -- **Project Name:** Interstellar - Wallet Phase 1 - **Team Name:** Interstellar - **Payment Address:** Ethereum - 0xc5C54DcD7b76b3B26ab4a02f191338F31aD732f6 (ETH) -- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview :page_facing_up: - - ### Overview - “The blockchain ecosystem needs an easy to use interface with hardware wallet security to reach the mass market.” - + The main pain points of non-custodial wallet solutions still are: + - **User experience** [Can an easy to set-up wallet be an efficient customer acquisition tool for DeFi players?](https://medium.com/@jlleleu/can-be-an-easy-to-set-up-wallet-an-efficient-customer-acquisition-tool-for-defi-players-8600812fe01e) -- **Security** [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) +- **Security** [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) > We think that current wallet solutions slow down the DeFi adoption. - Interstellar is a novel non-custodial peace of mind mobile wallet with a hardware security level. Based on a Substrate blockchain and SubstraTEE/IntegriTEE workers. **We can now provide the same hardware security level as hardware wallets with only a mobile and a blockchain** ![Grant-Scheme-White (1)](https://user-images.githubusercontent.com/4605611/145108720-becb76be-6c16-46c8-af69-7e953e5a166d.png#gh-dark-mode-only) - - - ![Grant-Scheme-Black (3)](https://user-images.githubusercontent.com/4605611/145108818-6f8b6158-6c27-4f0d-a104-9d2469c73636.png#gh-light-mode-only) - - **Thanks to Trusted User Interface TUI on mobile and Trusted Execution Environment on both mobile and blockchain nodes** Because TUI is not yet avalaible on all mobile devices we use a Garbled Circuit/Visual Cryptography scheme which provides an alternative that will be complementary down the road to mitigate potential flaws in TUI. - - - ![Iphone-Android-TUI-White (1)](https://user-images.githubusercontent.com/4605611/145201585-5d106219-e51e-44d3-8c1b-95fe99e71455.png#gh-dark-mode-only) ![Iphone-Android-TUI-Black (1)](https://user-images.githubusercontent.com/4605611/145201886-30bafb07-fc1c-4dc0-acf9-f0e9f163fa66.png#gh-light-mode-only) +#### Features - - - - -#### Features: - **Hardware security Level** - TEE on nodes and mobiles (incl. TUI), garbled circuits and visual cryptography secure interface - **Just download an app** - no registration, PIN, password, passphrase, private key or any secret to store or remember - **Multichain Wallet** - securely store and interact with native cryptocurrency coins and tokens from multiple blockchains - **Confirm a transaction with ONLY ONE SCREEN** - no SMS to wait for, no additional 2FA app to use, no QR code to scan -- **Up to 1,000,000 tps** - no tps limit due to slow consensus, thanks to IntegriTEE layer 2 based on hardware enclave technology -- **Social Recovery Service** - leverages the existing Substrate pallet and a novel decentralized autonomous recovery service +- **Up to 1,000,000 tps** - no tps limit due to slow consensus, thanks to IntegriTEE layer 2 based on hardware enclave technology +- **Social Recovery Service** - leverages the existing Substrate pallet and a novel decentralized autonomous recovery service + > We hope that we will be able to provide a response to the related RFP in the following phases -- **Features to securely send coins with social network messages (even to persons with no-wallet)** - explained in [Can an easy to set-up wallet be an efficient customer acquisition tool for DeFi players?](https://medium.com/@jlleleu/can-be-an-easy-to-set-up-wallet-an-efficient-customer-acquisition-tool-for-defi-players-8600812fe01e) +- **Features to securely send coins with social network messages (even to persons with no-wallet)** - explained in [Can an easy to set-up wallet be an efficient customer acquisition tool for DeFi players?](https://medium.com/@jlleleu/can-be-an-easy-to-set-up-wallet-an-efficient-customer-acquisition-tool-for-defi-players-8600812fe01e) -#### Our solution is designed to support blockchain and DeFi mass market adoption with: +#### Our solution is designed to support blockchain and DeFi mass market adoption with - **A decentralized key & asset management service** where the user’s privates keys and signature programs are stored and executed in TEE nodes - **A decentralized Trusted Transaction Validation protocol** that leverages TEE and TUI features on mobile, combined with One Time Garbled Circuits and Visual Cryptography to provide a **Trusted Authentication and Trusted UI layer** on user devices - - - - -The **Interstellar - Wallet Phase 1** W3F Grant Proposal focuses on two of the core components of the Interstellar solution: +The **Interstellar - Wallet Phase 1** W3F Grant Proposal focuses on two of the core components of the Interstellar solution: - A Substrate Off-Chain Worker OCW Garbled Circuit Factory GCF to manage an external garbled circuit generator service (designed to be used by Substrate developers regardless of the Interstellar solution) - An implementation of the Trusted Transaction Validation protocol in Substrate pallets to demonstrate the usage of GCF within a Substrate framework and with a mobile Garbled Circuit evaluator client @@ -87,22 +67,18 @@ Following are other use cases of the Garbled Circuit Factory: - Proof of history of legitimate computation with reusable Garbled Circuit (Interstellar ongoing research: Detection of adverse code execution during short transaction sessions - work in progress) - Post Quantum encryption and signature scheme implementations (NIST candidate examples) - ### Project Details - #### [Detailed documentation](https://docs.google.com/document/d/1RTPx4EeA0Ek33f-8_Dj7p-qjzBp6VqLrrXNhIrwvFWI/edit?usp=sharing) on the project - **OCW Garbled Circuit Factory** - **Transaction Validation protocol pallets (including mobile registry)** - **Transaction Validation Screen Technology (Trusted/Secure UI)** - - **Mobile client GC evaluator** - - - + - **Mobile client GC evaluator** #### Garbled Circuit Factory **previous work** -The team has already developed a strong authentication solution with circuits based on JustGarble implementation https://cseweb.ucsd.edu/groups/justgarble/ that we customized with Free XOR and Half Gates and other specific improvements for our needs (pre-computation of our Visual Cryptography Circuits). + +The team has already developed a strong authentication solution with circuits based on JustGarble implementation that we customized with Free XOR and Half Gates and other specific improvements for our needs (pre-computation of our Visual Cryptography Circuits). We achieved a production ready platform with significant performance on the logic circuit and garbled circuit production with AES-NI. The whole pipeline uses optimized memory management and avoids serialization/deserialization of the different circuit formats: HDL->non-garbled->garbled. ------------ @@ -114,18 +90,16 @@ We achieved a production ready platform with significant performance on the logi 4 circuits_per_hour : 639975 ``` - ![1844c95c-1b74-4987-8466-4ba14da41ff3 (Custom)](https://user-images.githubusercontent.com/4605611/141327055-ea10f548-d6d2-4b1a-af2e-a059f2f67673.png) - - ``` 5,65 ms per circuits on a Processor 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz, 2304 Mhz, 8 Core(s), 16 Logical Processor(s) ``` - -------------------------- + #### Technology stack + - VHDL - C/C++ - Java/Kotlin/Swift @@ -133,12 +107,6 @@ We achieved a production ready platform with significant performance on the logi - Rust/Substrate - IPFS - - - - - - ### Ecosystem Fit > Where and how does your project fit into the ecosystem? @@ -146,15 +114,10 @@ We achieved a production ready platform with significant performance on the logi This project is the first phase of a wallet project. Although, we think that our Trusted Transaction Validation protocol could bring a novel approach to address UX/UI security issues regardless of other features of our frictionless wallet. We designed our validation transaction protocol to benefit to other wallets or Dapps. We think it could also be complementary down the road to mobile light clients like Substrate Connect (check **Future Plans** section). - - ![TTV overview overview drawio](https://user-images.githubusercontent.com/4605611/144742049-54d3a212-b471-4a69-9f44-adfb150814ca.png#gh-light-mode-only) - ![TTV overview overview dark drawio](https://user-images.githubusercontent.com/4605611/144738926-e6f0db47-f7ff-4382-ae5d-251420e23a61.png#gh-dark-mode-only) - - >Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? We want to target Dapp providers in the DeFi ecosystem with developer tools to integrate our solution with their Dapps. We think that our value proposition should be attractive to them. @@ -167,14 +130,13 @@ The need for a wallet to be simpler to set-up and use, as well as the need for h Math Wallet and Gluon are close to our solution. -We think that we could bring a better user experience, security and performance, thanks to a highly scalable layer 2 based on SubstraTEE: +We think that we could bring a better user experience, security and performance, thanks to a highly scalable layer 2 based on SubstraTEE: - Math Wallet is based on MPC that requires heavier computation resources. They also envision smartcards with a screen for their users. It's comparable to our level of security, but more expensive, cumbersome to use, less flexible and more complex to deploy than our solution. - + - Gluon QR code based transaction confirmation that requires 2 screens is more cumbersome for the user. Moreover, this scheme is already exposed to banking trojans with overlay capabilities*. Although their TPM based approach could be complementary down the road to TEE, to mitigate potential future flaws on Intel SGX. -> *see: A high level attack description on solutions that use QR code for transaction confirmations [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) - +> *see: A high level attack description on solutions that use QR code for transaction confirmations [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) ## Team :busts_in_silhouette: @@ -189,12 +151,11 @@ We think that we could bring a better user experience, security and performance, - Aude Bourdouxhe - Philippe Salats (advisor) - ### Contact - **Contact Name:** Jean-Luc Leleu - **Contact Email:** jeanluc.leleu@protonmail.com -- **Website:** https://www.interstellar.gg/ +- **Website:** ### Legal Structure @@ -202,33 +163,30 @@ We think that we could bring a better user experience, security and performance, - **Registered Legal Entity:** N/A - we are still in the process of establishing a legal entity. ### Team's experience + [Team deck](https://docs.google.com/presentation/d/1AuM5YO4ysFqoj3uquQ46NJIprDSaALZrqUqAef-ITns/edit?usp=sharing) We are now multiple security and fintech entrepreneurs, security researchers, patents fillers who turned open-source developers and blockchain enthusiasts. ### Team Code Repos -- https://github.com/Interstellar-Network - -- https://github.com/nathanprat +- +- ### Team LinkedIn Profiles (if available) -- https://www.linkedin.com/in/jlleleu/ Jean-Luc Leleu +- Jean-Luc Leleu -- https://www.linkedin.com/in/nathan-prat/ Nathan Part - -- https://www.linkedin.com/in/eliotjfl/ Eliot Leleu - -- https://www.linkedin.com/in/jlhoenen/ Jean-Louis Hoenen +- Nathan Part -- https://www.linkedin.com/in/aude-bourdouxhe-40656b28/ Aude Bourdouxhe - -- https://www.linkedin.com/in/philippesalats/ Philippe Salats (advisor) +- Eliot Leleu +- Jean-Louis Hoenen +- Aude Bourdouxhe +- Philippe Salats (advisor) ## Development Roadmap :nut_and_bolt: @@ -253,11 +211,8 @@ We are now multiple security and fintech entrepreneurs, security researchers, p | 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | | 1. | GCF Substrate Interface | GCF external service interface to interact with the following Substrate modules and IPFS. | | 2. | Substrate module: GCF CFG | We will create a Substrate GCF configuration pallet that will store GCF encrypted configuration information on chain (including cid of master circuit file, master key and other security parameter to ensure security of circuit production. | -| 3. | Substrate GCF CFG CLI| A CLI to set-up GCF configuration pallet. | +| 3. | Substrate GCF CFG CLI| A CLI to set-up GCF configuration pallet. | | 4. | Substrate module: OCW GCF | We will create an OCW pallet that will control and interact with GCF external service - Launch GC production and get resulted GC cid on IPFS. | - - - ### Milestone 2 — GC Management in Substrate modules and Transaction Validation protocol use case (first part) @@ -274,7 +229,7 @@ We are now multiple security and fintech entrepreneurs, security researchers, p | 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | | 1. | Substrate module OCW GCP | We will create an OCW GC provider to interact with a GC evaluator/IPFS client. | | 2. | Substrate module: Authenticator| We will create a Substrate Authenticator pallet that will implement the Transaction Validation protocol to manage GC evaluator and IPFS client.| -| 3. | Substrate GCP CLI| A CLI to request GC cid for evaluation. | +| 3. | Substrate GCP CLI| A CLI to request GC cid for evaluation. | ### Milestone 3 — Transaction Validation protocol with mobile use case (second part) @@ -309,8 +264,6 @@ We are now multiple security and fintech entrepreneurs, security researchers, p | 1. | Substrate modules Authenticator port in TEE | We will migrate Authenticator in SubstraTEE/IntegriTEE workers. | | 2. | Substrate module Mobile Registry port in TEE | We will migrate a part of the Mobile Registry pallet in SubstraTEE/IntegriTEE workers. | - - ### Milestone 5 — GCF in TEE - **Estimated Duration:** 1 month @@ -324,14 +277,10 @@ We are now multiple security and fintech entrepreneurs, security researchers, p | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 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 what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | -| 1. | GCF external service in TEE | We will migrate GCF service in TEE/Intel SGX with Asylo framework. | - - +| 1. | GCF external service in TEE | We will migrate GCF service in TEE/Intel SGX with Asylo framework. | ## Future Plans - - >How we intend to use, enhance, promote and support your project in the short term: - We aim to create a user community and get in talks with Dapp and especially DeFi players with a tailored value proposition for them @@ -339,7 +288,6 @@ We are now multiple security and fintech entrepreneurs, security researchers, p - Continuous Liquidity Pool (native cross-chain swaps) - Seignorage - Quadratic Voting - - Wallet MVP launch with basic features including Social Recovery and Key management service (potential following grant application submissions) @@ -353,18 +301,15 @@ We are now multiple security and fintech entrepreneurs, security researchers, p - Bounty to crack our transaction validation protocol when both Android protected confirmation and detection of adverse code execution will be deployed - - Continuous Liquidity Pool (like THORChain but with higher security and performance that leverages TEE/MPC/TTS + Trusted Transaction Validation protocol with multisig options (mobiles + yubikey) for validators and large liquidity owners - - - Seignorage mechanism by creating synthetic assets (like UST on the Terra blockchain) - - - Quadratic Voting/Funding features to incentivize the CLP and Seignorage functions and address potential future use cases +- Continuous Liquidity Pool (like THORChain but with higher security and performance that leverages TEE/MPC/TTS + Trusted Transaction Validation protocol with multisig options (mobiles + yubikey) for validators and large liquidity owners ->The team's long-term plans and intentions in relation to it. +- Seignorage mechanism by creating synthetic assets (like UST on the Terra blockchain) +- Quadratic Voting/Funding features to incentivize the CLP and Seignorage functions and address potential future use cases -- Include a TEE layer 2 to manage a Root of trust based on full HSM hardware (with YubiHSM type of solution) to provide a 3 tier distributed HSM capability - +>The team's long-term plans and intentions in relation to it. +- Include a TEE layer 2 to manage a Root of trust based on full HSM hardware (with YubiHSM type of solution) to provide a 3 tier distributed HSM capability - Investigate potential integration with Substrate Connect to increase the security and flexibility of our solution with potential additional on-chain/off-chain data/features at mobile/browser level @@ -372,13 +317,14 @@ We are now multiple security and fintech entrepreneurs, security researchers, p ![3T DHSM overview dark drawio](https://user-images.githubusercontent.com/4605611/144741651-ff9f0bb0-91cb-4b76-8f0e-097395303723.png#gh-dark-mode-only) - - Research on other human brain decryption capabilities (like Visual Cryptography, Audio Cryptography, etc...): the long term goal is to increase our capabilities to differentiate bots with IA capabilities from real humans ([Review of the use of human senses and capabilities in cryptography](https://www.sciencedirect.com/science/article/pii/S1574013720304408)) ## Additional Information :heavy_plus_sign: -> **How did you hear about the Grants Program?** +> **How did you hear about the Grants Program?** + - We are following the Polkadot ecosystem since its early stage + > Others -- We have just started a conversation with a team working in stealth mode on a massive blockchain project that is interested in our solution +- We have just started a conversation with a team working in stealth mode on a massive blockchain project that is interested in our solution diff --git a/applications/InvArch.md b/applications/InvArch.md index c173df52d27..390fb99f974 100644 --- a/applications/InvArch.md +++ b/applications/InvArch.md @@ -1,22 +1,23 @@ -# W3F Grant Proposal +# The InvArch - INV4 Frame : IP Assets, Licensings, & CLI tool for the Substate ecosystem. -* **Project Name:** The InvArch - INV4 Frame : IP Assets, Licensings, & CLI tool for the Substate ecosystem. -* **Team Name:** InvArch Network -* **BTC Payment Address:** bc1qr2wg0snstgn4d2wc0alhhyxs32j58hhdrh5zal (PLEASE NOTE CHANGE) -* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Team Name:** InvArch Network +- **BTC Payment Address:** bc1qr2wg0snstgn4d2wc0alhhyxs32j58hhdrh5zal (PLEASE NOTE CHANGE) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview :page_facing_up: ### Overview -* The InvArch Network is the cross-chain IP development & authentication hub built on Polkadot. InvArch provides a proven & validated "best-to-market" -environment for IP Assets & dApps, where as the InvArch Tinkernet provides a "first-to-market" bleeding-edge environment on Kusama for testing. +- The InvArch Network is the cross-chain IP development & authentication hub built on Polkadot. InvArch provides a proven & validated "best-to-market" +environment for IP Assets & dApps, where as the InvArch Tinkernet provides a "first-to-market" bleeding-edge environment on Kusama for testing. The Eureka Relay is envisioned for future scaling improvements. -### The InvArch Network is powered by the INV4, On-Chain Innovation Funding (OCIF), & Cross-Chain Authentication (XCA) protocols. -* INV4 is responsible for defining how IP Assets are defined, stored, & interacted with across Web3. -* OCIF harnesses new & transparent funding possibilities to direct wealth towards the incentivization of realizing IP & unlocking true value. -* XCA unlocks the power of a trustless XC file tracking & data fingerprinting solution that realizes files just as uniquely as NFTs do with CIDs. +### The InvArch Network is powered by the INV4, On-Chain Innovation Funding (OCIF), & Cross-Chain Authentication (XCA) protocols + +- INV4 is responsible for defining how IP Assets are defined, stored, & interacted with across Web3. + +- OCIF harnesses new & transparent funding possibilities to direct wealth towards the incentivization of realizing IP & unlocking true value. +- XCA unlocks the power of a trustless XC file tracking & data fingerprinting solution that realizes files just as uniquely as NFTs do with CIDs. Under this grant, the [InvArch INV4 FRAME](https://github.com/InvArch/InvArch-Frames/tree/main/INV4) will be released & maintained by the InvArch Network team. The INV4 FRAME is a Rust Pallet Module for Substrate-based chains that realizes the INV4 protocol, and as a result, the possibility for @@ -30,29 +31,32 @@ mission. We have also held many exciting discussions with other Parachain teams ### Project Details -* [InvArch Website](https://invarch.network/) -* [InvArch EduSeries 1 (Background)](https://invarch.medium.com/invarch-eduseries-1-the-i-p-war-zone-innovation-graveyard-we-live-in-1f11ded41b5f) -* [InvArch EduSeries 2 (IPS & IPF)](https://invarch.medium.com/invarch-eduseries-2-blockchains-bright-light-a-shining-future-for-ip-rights-164b7a4eaba5) -* [InvArch EduSeries 3 (IP License)](https://invarch.medium.com/invarch-eduseries-3-web3s-super-highway-the-future-of-transporting-ip-rights-ce1368800927) -* [InvArch EduSeries 4 (IPT & SIPA)](https://invarch.medium.com/invarch-eduseries-4-the-sipa-revolution-a-new-golden-age-for-innovation-3e90aed4a57) +- [InvArch Website](https://invarch.network/) +- [InvArch EduSeries 1 (Background)](https://invarch.medium.com/invarch-eduseries-1-the-i-p-war-zone-innovation-graveyard-we-live-in-1f11ded41b5f) +- [InvArch EduSeries 2 (IPS & IPF)](https://invarch.medium.com/invarch-eduseries-2-blockchains-bright-light-a-shining-future-for-ip-rights-164b7a4eaba5) +- [InvArch EduSeries 3 (IP License)](https://invarch.medium.com/invarch-eduseries-3-web3s-super-highway-the-future-of-transporting-ip-rights-ce1368800927) +- [InvArch EduSeries 4 (IPT & SIPA)](https://invarch.medium.com/invarch-eduseries-4-the-sipa-revolution-a-new-golden-age-for-innovation-3e90aed4a57) -
          - +
          +
          -### InvArch approaches ideas (IP) as a set of non-fungible components: The INV4 Protocol -* IP Sets - Either a Root or Parent IP Set, and/or a Child Subset (collections) of interchangeable & freely composable IP Files & NFTs. -* IP Files - NFT-based files that which can emulate or contain any content or data as found as any other file on the internet & local devices. -* IP Licenses - On-chain Licensing agreements pegged to an IP Set that can be used to allocate ownership, manage custom access, & define utility. -* IP Tokens - Fungible tokens pegged to an IP Set & managed using an IP License; multiple unique classes of IP Tokens can be pegged to the same IP Set. +### InvArch approaches ideas (IP) as a set of non-fungible components: The INV4 Protocol + +- IP Sets - Either a Root or Parent IP Set, and/or a Child Subset (collections) of interchangeable & freely composable IP Files & NFTs. -* When interacting with `Pallet_ips` users can call the following functions `create_ips`, `destroy`, `append`, `remove`, `Allow_replica`, `Disallow_replica`, & `Create_replica`. -* When interacting with `Pallet_ipf` users can call the following functions: `mint` & `burn`. -* When interacting with `Pallet_ipl` users can call the following functions: `set_asset_weight` & `set_permission`. -* When interacting with `Pallet_ipt` users can call the following functions: `mint`, `burn`, `create_subasset`, `operate_multisig`, `vote_multisig`, `withdraw_vote_multisig`, `burn`. -* While some hidden functions are only callable by the actual Pallets in the INV4 FRAME themselves. +- IP Files - NFT-based files that which can emulate or contain any content or data as found as any other file on the internet & local devices. +- IP Licenses - On-chain Licensing agreements pegged to an IP Set that can be used to allocate ownership, manage custom access, & define utility. +- IP Tokens - Fungible tokens pegged to an IP Set & managed using an IP License; multiple unique classes of IP Tokens can be pegged to the same IP Set. + +- When interacting with `Pallet_ips` users can call the following functions `create_ips`, `destroy`, `append`, `remove`, `Allow_replica`, `Disallow_replica`, & `Create_replica`. +- When interacting with `Pallet_ipf` users can call the following functions: `mint` & `burn`. +- When interacting with `Pallet_ipl` users can call the following functions: `set_asset_weight` & `set_permission`. +- When interacting with `Pallet_ipt` users can call the following functions: `mint`, `burn`, `create_subasset`, `operate_multisig`, `vote_multisig`, `withdraw_vote_multisig`, `burn`. +- While some hidden functions are only callable by the actual Pallets in the INV4 FRAME themselves. ### Technologies + 1. Rust 2. Substrate 3. Polkadot.js @@ -62,135 +66,148 @@ mission. We have also held many exciting discussions with other Parachain teams ### InvArch INV4 FRAME ### 1. IP Sets & IP Files -* `Pallet_ips` - Provides basic functionality for creating and managing an `IPSet`. You can think of an `IPSet` as an idea, which is basically a collection of components (intellectual property tokens) that define and describe that idea. -* `Pallet_ipf` - Provides basic functionality for creating and managing an `IPToken`. You can think of an `IPToken` as a component of an idea. For example, a business summary PDF file, or even a 3D rendering of a prototype mold. When combined and stored in an `IPSet`, that collection forms the foundtion for an idea. The more detailed and/or comprehensive an `IPSet` is, the stronger the idea. -
          - +- `Pallet_ips` - Provides basic functionality for creating and managing an `IPSet`. You can think of an `IPSet` as an idea, which is basically a collection of components (intellectual property tokens) that define and describe that idea. + +- `Pallet_ipf` - Provides basic functionality for creating and managing an `IPToken`. You can think of an `IPToken` as a component of an idea. For example, a business summary PDF file, or even a 3D rendering of a prototype mold. When combined and stored in an `IPSet`, that collection forms the foundtion for an idea. The more detailed and/or comprehensive an `IPSet` is, the stronger the idea. + +
          +
          ### 2. IP Licenses & Tokens -* `Pallet_dev` - Provides basic functionality for structuring, managing, and listing a `DEV`(Decentralized Entrepreneurial Venture). You can think of a `DEV` as an agreement between multiple parties to come together as cofounders over a project in order to contribute towards an `IPSet`'s actualization. -* `Pallet_dao` - Provides basic functionality for creating and managing a `DAO` that helps govern a `DEV`. You can think of a `DAO` as a `DEV`'s governance mechanism. It helps regulate the and ensure the integrity and prudence of participants within a `DEV`. -* `Pallet_worklog` - Provides basic functionality for creating and managing a `WorkLog` within a `DEV`. You can think of a `Worklog` as a `DEV`'s method of recording and storing milestone/deliverables progressions and completions. -
          - +- `Pallet_dev` - Provides basic functionality for structuring, managing, and listing a `DEV`(Decentralized Entrepreneurial Venture). You can think of a `DEV` as an agreement between multiple parties to come together as cofounders over a project in order to contribute towards an `IPSet`'s actualization. + +- `Pallet_dao` - Provides basic functionality for creating and managing a `DAO` that helps govern a `DEV`. You can think of a `DAO` as a `DEV`'s governance mechanism. It helps regulate the and ensure the integrity and prudence of participants within a `DEV`. +- `Pallet_worklog` - Provides basic functionality for creating and managing a `WorkLog` within a `DEV`. You can think of a `Worklog` as a `DEV`'s method of recording and storing milestone/deliverables progressions and completions. + +
          +
          -* Ownership can be fractionalized using multiple pegged fungible assets representing ownership (ARO). An ARO is (typically) reflected in the first IP Token (IPT) attached to an IP Set. The asset ID of an ARO is defined in a copyright ownership agreement, and there can be multiples of these fungible assets. +- Ownership can be fractionalized using multiple pegged fungible assets representing ownership (ARO). An ARO is (typically) reflected in the first IP Token (IPT) attached to an IP Set. The asset ID of an ARO is defined in a copyright ownership agreement, and there can be multiples of these fungible assets. ### Ecosystem Fit -:link: **Chains and Pallets**
          +:link: **Chains and Pallets**
          InvArch applies the categories below: -* NFT -* Governance/DAO -* Other (IP Assets) + +- NFT +- Governance/DAO +- Other (IP Assets) ### Project Uniqueness -* The world's first truly composable network for fully unlocking IP assets & on-chain IP attribution solution (that is flexible for its assets to experience international compliance in business, copyright, & legal transactions. InvArch revolutionizes the world of innovation beginning at the very start of development & pushes the bounds of web3 by taking existing concepts & challenging them to be different and better. By unlocking new doors & redefining what’s possible, InvArch will revolutionize the worlds of technical development & real-world collaboration down to their very core. + +- The world's first truly composable network for fully unlocking IP assets & on-chain IP attribution solution (that is flexible for its assets to experience international compliance in business, copyright, & legal transactions. InvArch revolutionizes the world of innovation beginning at the very start of development & pushes the bounds of web3 by taking existing concepts & challenging them to be different and better. By unlocking new doors & redefining what’s possible, InvArch will revolutionize the worlds of technical development & real-world collaboration down to their very core. ### Target Audience -* Entrepreneurs/Innovators -* Developers/DAOs/Artists -* Educators/Researchers -* Philanthropists + +- Entrepreneurs/Innovators + +- Developers/DAOs/Artists +- Educators/Researchers +- Philanthropists ### Problem Addressed -* On-chain IP attribution (Achieved with this grant proposal). -* International flexibility for compliance (Achieved with this grant proposal). -* Barriers of access to startup capital. (OCIF Protocol) -* On-chain donations for access & transparency. (OCIF Protocol) -* File piracy & inability to securely expose data. (XCA Protocol) + +- On-chain IP attribution (Achieved with this grant proposal). + +- International flexibility for compliance (Achieved with this grant proposal). +- Barriers of access to startup capital. (OCIF Protocol) +- On-chain donations for access & transparency. (OCIF Protocol) +- File piracy & inability to securely expose data. (XCA Protocol) ## Team :busts_in_silhouette: -### Team members +### Team members + (Development & Engineers) -* [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development -* [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development -* [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development -* [Mindaugas Savickas](https://www.linkedin.com/in/savickas) - Co-Founder & Head of Ecosystem Development -* [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer +- [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development +- [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development +- [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development +- [Mindaugas Savickas](https://www.linkedin.com/in/savickas) - Co-Founder & Head of Ecosystem Development +- [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer -* [Brunk Škvorc](https://www.linkedin.com/in/swader) - Technical Advisor (Founder, RMRK) -* [Marvin Tong](https://twitter.com/marvin_tong) - Product Advisor (Founder, Phala Network) +- [Brunk Škvorc](https://www.linkedin.com/in/swader) - Technical Advisor (Founder, RMRK) +- [Marvin Tong](https://twitter.com/marvin_tong) - Product Advisor (Founder, Phala Network) ### Contact -* **Contact Name:** Dakota Barnett -* **Contact Email:** dakota@invarch.network -* **Website:** [https://invarch.network](https://www.invarch.network) +- **Contact Name:** Dakota Barnett +- **Contact Email:** dakota@invarch.network +- **Website:** [https://invarch.network](https://www.invarch.network) ### Legal Structure -The InvArch Association.
          -Baarerstrasse 86,
          -6300 Zug, Switzerland
          +The InvArch Association. + +Baarerstrasse 86, + +6300 Zug, Switzerland ### Founders' experiences -* [Dakota Barnett](https://www.linkedin.com/in/dakotasb97) has experience succesfully directing and leading multi-national teams, overseeing and directing -succesful project management strategies, and scaling large operations. He's a seasoned developer, programming in JavaScript (3yrs), Node.js (2yrs), +- [Dakota Barnett](https://www.linkedin.com/in/dakotasb97) has experience succesfully directing and leading multi-national teams, overseeing and directing +succesful project management strategies, and scaling large operations. He's a seasoned developer, programming in JavaScript (3yrs), Node.js (2yrs), React.js (2yrs), Python (2yrs), Rust (1yr), and the Substrate framework (1yr). Past work includes private projects for previous employers focused on machine learning, task automation, and website development. 💡 -* [Gabriel Facco de Arruda](https://github.com/arrudagates) has experience as a Rust Developer, programming for the past 3 years, and as a developer in +- [Gabriel Facco de Arruda](https://github.com/arrudagates) has experience as a Rust Developer, programming for the past 3 years, and as a developer in the Web3 ecosystem. Gabriel is a a dedicated programmer and DeFi ninja who loves cutting edge technology and all things Substrate/Rust. He is committed to building applications that help promote a more decentralized global economy, and comes with past experience developing and scaling such applications. He brings direct experience developing applications for the Substrate ecosystem and as a Polkadot ecosystem contributor dedicated to building the future. 🧠 -* [Kresna Sucandra](https://github.com/SHA888) is a dedicated programmer and Parity/Substrate enthusiast. Kusandra has been dedicated for the past year +- [Kresna Sucandra](https://github.com/SHA888) is a dedicated programmer and Parity/Substrate enthusiast. Kusandra has been dedicated for the past year learning everything there is to know about the Web3 ecosystem. Kresna is a medical doctor turned programmer with a background in Substrate blockchain development focusing on multi-chain interoperability, DeFi, NFTs, and the Metaverse. He brings first-hand insights and experience as a former blockchain -startup co-founder and developer with a history focusing on JavaScript and Rust programming. Kresna is a Polkadot ecosystem contributor who loves +startup co-founder and developer with a history focusing on JavaScript and Rust programming. Kresna is a Polkadot ecosystem contributor who loves entrepreneurship. 🚀 -* [Mindaugas Savickas](https://www.linkedin.com/in/savickas) is a veteran marketing advisor and fundraising rockstar with a background providing strategic marketing solutions and scaling over 40+ product & marketing teams worldwide. He Provides a proven history of success and strategic insights as a tech marketing guru who lives & breathes outside of the box. 📈 +- [Mindaugas Savickas](https://www.linkedin.com/in/savickas) is a veteran marketing advisor and fundraising rockstar with a background providing strategic marketing solutions and scaling over 40+ product & marketing teams worldwide. He Provides a proven history of success and strategic insights as a tech marketing guru who lives & breathes outside of the box. 📈 ### Team Code Repos -* InvArch Github: https://github.com/InvArch -* InvArch Node https://github.com/InvArch/InvArch-node -* InvArch Frames : https://github.com/InvArch/InvArch-Frames -* InvArch INV4 FRAME : https://github.com/InvArch/InvArch-Frames/tree/main/INV4 +- InvArch Github: +- InvArch Node +- InvArch Frames : +- InvArch INV4 FRAME : Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. -* [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development -* [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development -* [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development -* [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer +- [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development +- [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development +- [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development +- [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer ### Team LinkedIn Profiles (if available) -* [Dakota Barnett](https://www.linkedin.com/in/dakotasb97), Founder -* [Gabriel Facco de Arruda](https://www.linkedin.com/in/gabriel-facco-de-arruda-00880787), Sr. Rust Dev -* [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra/), Substrate Dev -* [Mindaugas Savickas](https://www.linkedin.com/in/savickas), Head of Marketing +- [Dakota Barnett](https://www.linkedin.com/in/dakotasb97), Founder +- [Gabriel Facco de Arruda](https://www.linkedin.com/in/gabriel-facco-de-arruda-00880787), Sr. Rust Dev +- [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra/), Substrate Dev +- [Mindaugas Savickas](https://www.linkedin.com/in/savickas), Head of Marketing ## Development Status :open_book: -* InvArch is a project in the Substrate Builders Program. -* The INV4 protocol is complete & available for public testing. -* Gearing up for the launch of the Brainstorm Testnet (Solo-chain) on May 23rd, 2022. -* Preparing the InvArch Tinkernet for a crowdloan campaign & slot auction on the Kusama relay. +- InvArch is a project in the Substrate Builders Program. +- The INV4 protocol is complete & available for public testing. +- Gearing up for the launch of the Brainstorm Testnet (Solo-chain) on May 23rd, 2022. +- Preparing the InvArch Tinkernet for a crowdloan campaign & slot auction on the Kusama relay. -* INV4 v2 & xcINV4 (Est. August, 2022) will add additional functionality, wrapping of other Substrate NFTs, & authentication of assets. +- INV4 v2 & xcINV4 (Est. August, 2022) will add additional functionality, wrapping of other Substrate NFTs, & authentication of assets. ## Development Roadmap :nut_and_bolt: ### Overview -* **Full-Time Equivalent (FTE):** 2.5 -* **Total Costs:** $25,000 equivalent +- **Full-Time Equivalent (FTE):** 2.5 +- **Total Costs:** $25,000 equivalent ### Milestone 1 — Implement IP Pallets & Standards -* **Estimated duration:** 4 weeks -* **FTE:** 2 -* **Costs:** $10,000 equivalent +- **Estimated duration:** 4 weeks +- **FTE:** 2 +- **Costs:** $10,000 equivalent Goal - Develop Substrate Pallets that fully realize Git-level composability for NFTs; fully emulating file & folder functionalities. @@ -200,35 +217,35 @@ Goal - Develop Substrate Pallets that fully realize Git-level composability for | 0b. | Documentation | Documents containing the description of the whole architecture design for InvArch, an introduction video, and appropriate `README.md` files will be included. | | 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | -| 1. | Node Repo | Complete the deployment of the InvArch chain (https://github.com/InvArch/InvArch) | +| 1. | Node Repo | Complete the deployment of the InvArch chain () | | 2a. | Pallet_ips | Complete the development of [pallet_ips](https://github.com/InvArch/InvArch-Pallet-Library/tree/main/ips) and realize the IP Sets standard. | | 2b. | Pallet_ipf | Complete the development of [pallet_ipf](https://github.com/InvArch/InvArch-Pallet-Library/tree/main/ipt) and realize the IP Token Standard. | -| 3. | Article | We will write an **article** that explains the work done as part of the grant. | +| 3. | Article | We will write an **article** that explains the work done as part of the grant. | ### Milestone 2 — Implement DEV Pallets & Standards -* **Estimated duration:** 12 weeks -* **FTE:** 3 -* **Costs:** $15,000 equivalent +- **Estimated duration:** 12 weeks +- **FTE:** 3 +- **Costs:** $15,000 equivalent Goal - Develop and deliver the DEV Pallets & Standards for the InvArch Chain/InvArch Pallet Library | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| 0a. | License | GPLv3 | +| 0a. | License | GPLv3 | | 0b. | Documentation | An introduction video, and appropriate `README.md` files will be included. | | 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | | 1a. | Pallet_ipl | complete the development of [pallet_ipl](https://github.com/InvArch/InvArch-Frames/tree/main/INV4/pallet-ipl) and copyright & license structuring mechanism. | | 1b. | Pallet_ipt | Complete the development of [pallet_ipt](https://github.com/InvArch/InvArch-Frames/tree/main/INV4/pallet-ipt) and realize the refungible & multi-layer governance mechanisms. | | 2. | INV4-Git middleware | We will release a middleware tool for managing INV4 assets using the standard git CLI commands transparently. | -| 3. | Article & Video | We will write an **article** that explains the work done as part of the grant, as well as release a video walk through demonstrating the INV4 protocol | +| 3. | Article & Video | We will write an **article** that explains the work done as part of the grant, as well as release a video walk through demonstrating the INV4 protocol | ## Future Plans -* Launch the InvArchitects Assemble Program, the builders program of the InvArch Network. -* Finish Development on the On-Chain Innovation Funding (OCIF) & Cross-Chain Authentication (XCA) protocols. -* Maintain the Brainstorm Testnet, launch the Tinkernet Parachain on Kusama, & deploy the InvArch Network on Polkadot. +- Launch the InvArchitects Assemble Program, the builders program of the InvArch Network. +- Finish Development on the On-Chain Innovation Funding (OCIF) & Cross-Chain Authentication (XCA) protocols. +- Maintain the Brainstorm Testnet, launch the Tinkernet Parachain on Kusama, & deploy the InvArch Network on Polkadot. 1. GitArch - Decentralized, Incentivized, Open-Source On-Chain Repository Platform powered using INV4-Git. 2. Tinkerspace - A VR Sandbox for experimenting, collaborating, & simulating development using INV4 Assets. @@ -236,5 +253,5 @@ Goal - Develop and deliver the DEV Pallets & Standards for the InvArch Chain/Inv ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/JuniDB.md b/applications/JuniDB.md index a1372a9d416..15150b0b44b 100644 --- a/applications/JuniDB.md +++ b/applications/JuniDB.md @@ -1,4 +1,5 @@ -* **Project Name:** JuniDB +# JuniDB + * **Team Name:** Uddug * **Payment Address:** 0xc45eAd98E95D1962133d9c15847e2EA4E16dfD0b @@ -7,6 +8,7 @@ ### Overview It's a very highload action to store large amounts of data on-chain. The most-common and useful solution for decentralised apps is to use IPFS as a data storage and store on-chain only hashes. Our team inspired by the OrbitDB will focus on the scalability, decentralised, easy-learning solution for substrat developers that want to manipulate big amounts of data easily. + #### Key advantages * **Usability** - just integrate and code @@ -22,30 +24,32 @@ It's a very highload action to store large amounts of data on-chain. The most-co Working a lot with blockchain technologies, our team found that it’s data-driven, and thus there are rapidly growing interests in integrating them for more secure and efficient data storage and sharing.We are convinced that blockchain technologies change the world, and have been working hard to create more transparent solutions. We designed and built core infrastructure for decentralised projects. -We have been observing and learning Substrate technologies and find Polkadot as the best ecosystem for us to join depending on technology and strong market position. We believe that our protocol will be useful for other projects in the Polkadot ecosystem. +We have been observing and learning Substrate technologies and find Polkadot as the best ecosystem for us to join depending on technology and strong market position. We believe that our protocol will be useful for other projects in the Polkadot ecosystem. ### Project Details + Substrate pallet provides a configurable database module allows to store and manipulate a big amount of data. Pallet works as an offchain worker and connect data between blockchain and ipfs via offchain::worker. #### Encryption module + Built-in encryption module allows to create a secure database and encrypt all data before its uploading to the database with user account keys. With enabled encryption only account users have access to the database. Data could be decrypted via Web-application after receiving. Module is based on asymmetrical cryptography and uses an account public key to encrypt data on the blockchain side and a private key to decrypt data on the client side. -We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https://github.com/phayes/ecies-ed25519) crate to implement encryptions on backend side. +We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https://github.com/phayes/ecies-ed25519) crate to implement encryptions on backend side. ![scheme A](https://i.postimg.cc/gJds3kj9/encryption.png) -- receive data by RPC request -- Encrypt data by account public key -- Insert encrypted data into ipfs via offfchain::ipfs -- Insert received ipfs hash into storage +* receive data by RPC request +* Encrypt data by account public key +* Insert encrypted data into ipfs via offfchain::ipfs +* Insert received ipfs hash into storage ![scheme B](https://i.postimg.cc/Y9h66G7s/decryption.png) -- catch request to get data by RPC request -- get ipfs hash from storage -- fetch encrypted data from ipfs via offchain::ipfs -- receive encrypted data in RPC response -- decrypt data using user account private key via app ddecryption module +* catch request to get data by RPC request +* get ipfs hash from storage +* fetch encrypted data from ipfs via offchain::ipfs +* receive encrypted data in RPC response +* decrypt data using user account private key via app ddecryption module #### Technical stack @@ -62,6 +66,7 @@ We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https:/ * **ecies-ed25519** - encryption crate #### Public Methods + * **KeyValueInit(name)** - initialise new keyValue database * **KeyValueSet(key, value)** - set given value in keyValue database * **KeyValueGet(key)** - get value for given key @@ -76,74 +81,81 @@ We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https:/ * **HashAll(hash)** - get all hash fields #### Storage + * **Data Map** - mapping ipfs hashes and data keys * **Key-value** - database meta info #### Scheme 1. Palett structure + ![scheme C](https://i.postimg.cc/Hn1nkxGD/pallet.png) ##### Data uploading -- Rpc/wss request to pallet to insert data -- Validating data based on database schema -- Formatting data -- Encrypted (if needed) -- Store to ipfs via offchain::ipfs -- Retrieving ipfs hash with data -- Store ipfs hash into pallet storage +* Rpc/wss request to pallet to insert data +* Validating data based on database schema +* Formatting data +* Encrypted (if needed) +* Store to ipfs via offchain::ipfs +* Retrieving ipfs hash with data +* Store ipfs hash into pallet storage ##### Data retrieving + - RPC/wsss request to pallet to fetch get data -- Validating data query -- Get ipfs hash from storage -- Fetch data from ipfs via offchain::ipfs -- Return data object in response +* Validating data query +* Get ipfs hash from storage +* Fetch data from ipfs via offchain::ipfs +* Return data object in response #### Scheme 2. Interaction with Substrate + ![scheme D](https://i.postimg.cc/1zzJvmjQ/scheme.png) #### Infrastructure + Testing substrate nodes with offchain::orbitDB pallet orchestrated by kubernetes cluster deployed on GCP. + #### Ci/Cd + Ci/Cs organized by github actions + #### Frontend + Simple SPA web application powered by react and polkadot.js. Using for testing purposes. -### Ecosystem Fit +### Ecosystem Fit Pallet is suitable for substrate developers and strives to become a complex solution for data storage and manipulation. We expect that the project will be useful for the Web3 community. - ## Team :busts_in_silhouette: ### Team members -**Tech lead, backend:** Andrew Skurlatov +**Tech lead, backend:** Andrew Skurlatov -https://www.linkedin.com/in/andrew-skurlatov/ + -**Head of product:** Mike Manko +**Head of product:** Mike Manko -https://www.linkedin.com/in/mikhail-manko-97a491a2/ + -**Product design:** Anuar Zhumaev +**Product design:** Anuar Zhumaev -https://www.linkedin.com/in/yxorama/ + -**DevOps:** Ivan Podcebnev +**DevOps:** Ivan Podcebnev -https://www.linkedin.com/in/naykip/ + -**Data Science:** Constantine Czerniak +**Data Science:** Constantine Czerniak -https://www.linkedin.com/in/%D1%81czerniak/ + -**Frontend:** Nikita Velko - -https://www.linkedin.com/in/nikichv/ +**Frontend:** Nikita Velko + ### Contact @@ -151,7 +163,6 @@ https://www.linkedin.com/in/nikichv/ **Contact Email:** ms@uddug.com - ### Legal Structure **Registered Address:** PO301650, RUSSIA, UL. OVRAZHNAYA, D. 35, S. TETYAKOVKA, NOVOMOSKOVSKIJ R-N, OBL. TUL'SKAYA. @@ -164,28 +175,26 @@ Core of our team is of united, like-minded professionals with solid experience. Team range of experience begins from developing small scaled websites up to complex blockchain architectures. Our projects are diverse, but all of them share the need to have a software solution for humans. - ### Team Code Repos -http://github.com/andskur/ + -http://github.com/uddugteam/ + -### Commits -https://github.com/uddugteam/thc-node/commits/master +### Commits + -### Related domain -https://thc.uddug.com/ +### Related domain + ## Development Status :open_book: -We have already developed the pre-alfa pallet for **Trusted Health Council** [(https://github.com/uddugteam/thc-node)](https://github.com/uddugteam/thc-node). +We have already developed the pre-alfa pallet for **Trusted Health Council** [(https://github.com/uddugteam/thc-node)](https://github.com/uddugteam/thc-node). -Link to initial pull request (https://github.com/uddugteam/General-Grants-Program/blob/master/grants/speculative/trusted_health_consul.md). +Link to initial pull request (). Link to 2nd pull request -(https://github.com/uddugteam/Open-Grants-Program/blob/master/applications/ML-as-a-service.md). - +(). ## Development Roadmap :nut_and_bolt: @@ -193,7 +202,7 @@ Link to 2nd pull request * **Full-Time Equivalent (FTE):** 2.5 FTE * **Total Costs:** 28 000 USD -### Milestone 1 +### Milestone 1 * **Estimated Duration:** 1 month * **FTE:** 2.5 @@ -209,11 +218,10 @@ Link to 2nd pull request | 2. | Web application | Interacting with blockchain + form with fields to manipulate with data. Based on the substrate-front-end-template | | 3. | Docker image| We will provide a dockerfile to demonstrate the full functionality of testing Substrate chain with integrated Database pallet. | - ### Milestone 2 * **Estimated Duration:** 1 month -* **FTE:** 2.5 +* **FTE:** 2.5 * **Costs:** 7 000 USD | Number | Deliverable | Specification | @@ -228,7 +236,7 @@ Link to 2nd pull request ### Milestone 3 * **Estimated Duration:** 1 month -* **FTE:** 2.5 +* **FTE:** 2.5 * **Costs:** 7 000 USD | Number | Deliverable | Specification | @@ -244,7 +252,7 @@ Link to 2nd pull request ### Milestone 4 * **Estimated Duration:** 1 month -* **FTE:** 2.5 +* **FTE:** 2.5 * **Costs:** 7 000 USD | Number | Deliverable | Specification | @@ -259,7 +267,7 @@ Link to 2nd pull request ## Future Plans -Further development (adding new data storages, indexing system, concurrency queries) +Further development (adding new data storages, indexing system, concurrency queries) Community engagement diff --git a/applications/KSM-embeddable-tip-or-donate-button.md b/applications/KSM-embeddable-tip-or-donate-button.md index e2baef7e0b5..466bead9e15 100644 --- a/applications/KSM-embeddable-tip-or-donate-button.md +++ b/applications/KSM-embeddable-tip-or-donate-button.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Tip or Donate KSM Embeddable Button -- **Project:** Tip or Donate KSM Embeddable Button - **Proposer:** https://github.com/Shard-Labs - **Payment Address:** bc1q5njhr3r0mgd398yvma75nv48g69c590a0f0zcx diff --git a/applications/Koiverse.md b/applications/Koiverse.md index df52148dc3b..36297005df7 100644 --- a/applications/Koiverse.md +++ b/applications/Koiverse.md @@ -1,53 +1,39 @@ -# Koi Metaverse - Open Grants Program +# Koi Metaverse - - -* **Project:** Koi Metaverse -* **Proposer:** https://github.com/KoiMetaverse +* **Proposer:** * **Payment Address:** 0xfADc3c36E41D36796ca05B4D55b148725c804cE0 * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/678#issuecomment-1204360469) - # Project Overview - ## Overview - ### Introduction -Koi Metaverse aims to unlock the next-gen GameFi metaverse economies and it is building the digital collectibles platform for virtual GameFi NFTs. It is a fish collection blockchain game that combines token economy and NFT assets. It consists of a series of smart contracts, and all of the in-game assets belong to its players. Players can play to earn by collecting high mining power fish and growing them, creating a positive self-circulation. +Koi Metaverse aims to unlock the next-gen GameFi metaverse economies and it is building the digital collectibles platform for virtual GameFi NFTs. It is a fish collection blockchain game that combines token economy and NFT assets. It consists of a series of smart contracts, and all of the in-game assets belong to its players. Players can play to earn by collecting high mining power fish and growing them, creating a positive self-circulation. If pure-bred mining fish is reproduced, you can lock it into the pictorial book to mine the governance token, and use it to participate in the other DeFi activities. Koiverse creates a variety of NFT assets in the form of fish images and aims to become the BearBrick in the blockchain GameFi space and the brand new Axie Infinity on the Polkadot network. - ### Team Interest Our team has more than 10 years of game development experience and 3 years of blockchain game development experience. The number of accumulated registered users in the previous games is over 50 million globally. The highest number of active unique users exceeded 1 million. Koi team is also experts in innovative gaming mechanisms, sidechain implementation, tokenization economics and decentralized wallet integration. We are creating new kinds of virtual assets on Blockchain. Certainly we are the true Metaverse believers and builders who have strong motivation to unlock the Next-Gen GameFi Metaverse Economies. In Metaverse powered by Blockchain, we have seen the following core disruptive innovations: - - * Blockchain infrastructure leads to the property rights revolution. With blockchain, we can imagine a world in which contracts are embedded in digital code and stored in transparent, shared databases so that everyone could have the real ownership of properties. * Non-Fungible Token (NFT) changes the types and rules of games. NFT is a new form of unique digital asset designed to show someone has ownership of a unique virtual asset. It will become a new trend of virtual assets for creating, trading and collecting. * Tokenization and crypto creates brand-new business models. Crypto unlocks new rules of business models in game, like the concept of Play-to-Earn (P2E) which created new types of jobs and professions in digital Metaverse economies. - ## Project Details - ### Project Architecture The technical architecture of the project: ![](https://statics.fishnft.xyz/github/koi.png) - The gaming NFT protocols and Dapp consists of: - - * NFT Lottery Draw (NFT function) * NFT Auction Sale (NFT function) * NFT Minting (NFT function) @@ -57,51 +43,38 @@ The gaming NFT protocols and Dapp consists of: * Fish Mining (game function) * Pictorial Book Mining (game function) - #### NFT Functions **NFT Lottery Draw** - ### Types - - * `name` - activity name * `nft` - nft contract address * `noin` - coin contract address * `price` - fees needed to run lottery -* `total` - total number of lotteries +* `total` - total number of lotteries * `remain` - remnant quantity -* `limit` - nft limited per person -* `startTime` - activity start time +* `limit` - nft limited per person +* `startTime` - activity start time * `endTime` - activity end time - ### Functions - - * `lottery()` - lottery **NFT Auction Sale** - ### Types - - * `name` - activity name * `nft` - nft contract address * `coin` - coin contract address * `startTime` - activity start time * `endTime` - activity end time - ### Function - - * `fishList()` - read the fish list in the auction activity * `fishGeneList()` - read the fish gene list in the auction activity * `bid()` - users submit bids @@ -110,21 +83,15 @@ The gaming NFT protocols and Dapp consists of: **NFT Minting** - ### Types - - * `nft` - nft contract address * `coin` - coin contract address * `totalNft` - current NFT quantities in mining pool * `totalNftPower` - current total NFT mining power in mining pool - ### Function - - * `myNft()` - read staked NFT * `getNft()` - read one nft info * `earned()` - read mining profit @@ -133,80 +100,58 @@ The gaming NFT protocols and Dapp consists of: * `withdrawNftAll()` - withdraw all staked nfts * `getReward()` - acquire mining reward - #### NFT Assets **Fish NFT** - - * Each fish is composed of 14 genetic components: shape, color, pattern, eyes, mouth, pectoral fin, dorsal fin, caudal fin, decorations, invisible components, and breeding sequence. * The highest mining power of the fish is determined by the sum of each part’s mining power, gear buff, and the cultivation level. * When certain fish genes match, a mining power bonus and pictorial books will be activated. **Fist Tank NFT** - - * The fish can grow up in fish tanks. The cultivation time cycles are 10 days, 30 days, and 90 days, which respectively come with a maximum 30%, 120%, and 400% mining power increase. * Each fish tank may have unique features and different capacities. * Fish tanks and fish cannot be sold during the lock period. * In the cultivation time, the fish cannot engage in mining or breeding. - #### Game Functions **Fish Breeding** - - * The only way gamers can mint new fish NFT assets is to breed fish. The cost of the very first breeding is determined by the average mining power P of the parent fish and the average ecological mining power AP. The cost F=K*P/AP, tentatively K = 500. * The progeny genes are inherited from the parent fish genes, and each parent has a 50% chance to propagate its genes. * The scarcity of the fish gene is classified as normal, scarce, epic, and legendary. The scarce, epic, and legendary genes, respectively, have a 50%, 35%, and 25% chance to be inherited. There is a 1% chance to increase the gene scarcity level, or the genes will mutate into random and normal genes. **Fish Mining** - - * All fish with mining power can obtain reward tokens every day proportionately. The amount of reward token available to mine per day (M) is related to (F) the total sum of the fish (mining power>0) participating in mining. M=K*F^0.9，K as a constant, tentatively K=50. * Only the fish that are not being sold, bred, or locked by pictorial books can participate in mining. * Every time a fish participates in mining, it loses 4% of the mining power until it reaches 0. **Pictorial Book Mining** - - * A gamer can activate a pictorial book when acquiring some pure-bred fish with the built-in suites. * You can start mining reward tokens if you lock the right fish into the pictorial book. The locked fish must have full mining capacity. * There are 4 levels to each fish’s pictorial book: 0, 10, 30, and 90 growing up days in fish tanks. * When level 2, level 3 or level 4 fish are locked, the system automatically releases the low-level fish previously locked. You can only lock one fish, and you can double your points after collecting all level 4 fish, in all the colors, with the same suit. * The mined reward tokens are distributed according to the points and settled once a day. At the same time, the mining power is reduced by 4%. If the mining power is 0, then no more mining can be done. - #### Front End - - * Implement web front-end based on react.js and polkadot.js. Modules include: NFT Lottery Draw, NFT Auction Sale, NFT Minting, Fish and Fish Tank. * Implement web front-end based on react.js, polkadot.js and pixi.js. Game functions include Fishing Mining, Fish Breeding, Pictorial Book Mining. -* UI mockups: https://www.figma.com/file/0uuKT3XxB6hbzyFxLnzfAr/Koi-Metaverse?node-id=0%3A1 -* Fish Gene and Images: https://drive.google.com/drive/folders/1R4EoaDhoPkpxd9vchh7KLs-jx94pKad1?usp=sharing - +* UI mockups: +* Fish Gene and Images: ### Ecosystem Fit Existing GameFi NFT projects mainly focus on the public chains, games and collectible publishing, Marketplace, etc. Popular projects working in this segment include Axie Infinity (NFT game), Chiliz (sports-oriented underlying public chain), Flow (general NFT issuance public chain), and Opensea (general marketplace). We will add more game functions than Axie Infinity and build on the Substrate framework. We also can collaborate with native Polkadot NFT marketplace [RMRK](https://www.rmrk.app/) and [NFTMart](https://www.nftmart.io/). - - - # Team - ## Team Members - - * Anetta Sultygova - Project Lead * Euglena Liu - Product Manager * Yuan Li - Full-stack Developer @@ -215,43 +160,30 @@ Existing GameFi NFT projects mainly focus on the public chains, games and collec * Hongfeng Liu - Artistic Designer * Vladan Falcic - NFT Advisor - ## Team Website - - * [https://www.koi.io/](https://www.koi.io/) - ## Legal Structure - - * Koi Metaverse Ltd. is a company registered in the British Virgin Islands. - ## Team Experience Anetta Sultygova - - * 8-years project management and investing experience in the blockchain industry. She is good at structuring and organizing the teams around the projects. * Seasoned experience in NFT ecosystem and marketing strategy. * Marketing and community management in MILC, Realm, BloXmove and Metis etc. Euglena Liu - - * Product lead of fishchain and Paopaoyu (Top 10 web game on Renren “Chinese Facebook”). * 8-years gaming product design experience in the game industry. * Early player and investor in Axie Infinity ($AXS). Yuan Li - - * 10-years full stack software development experience * 5-years blockchain and smart contract development experience * Over 15 years of experiences in development and Management @@ -259,70 +191,49 @@ Yuan Li Tao Liu - - * 3-years of product management experience in the game industry. * 20-years of art design and animation experience. * Former Front-end Director of LightInBox, Fishchain and ShopperPlus. Vladan Falcic - - -* Blockchain and crypto enthusiast, he entered the crypto space back in 2014 and was mostly involved in early stage projects. -* In 2016, he started working with different projects, improving their marketing and establishing valuable partnerships. -* As the CEO of Squares Capital, he is working with several startup projects, advising them, improving their marketing and building the community. +* Blockchain and crypto enthusiast, he entered the crypto space back in 2014 and was mostly involved in early stage projects. +* In 2016, he started working with different projects, improving their marketing and establishing valuable partnerships. +* As the CEO of Squares Capital, he is working with several startup projects, advising them, improving their marketing and building the community. Jelly Ji - - * 5-years experience in html5 and front-end stack development. * Expert in mobile game development, H5 game development and blockchain game development * Bsc in Information Management and Information System of Beijing University of Posts and Telecommunications Hongfeng Liu - - * Senior UI and animation designer. * 3-years experience in blockchain game development - ## Team Code Repos - - * [https://github.com/KoiMetaverse](https://github.com/KoiMetaverse) - ## Team Linkedin Profiles - - * [https://www.linkedin.com/in/anetta-sultygova/](https://www.linkedin.com/in/anetta-sultygova/) * [https://www.linkedin.com/in/taoliu-designer/](https://www.linkedin.com/in/taoliu-designer/) * [https://www.linkedin.com/in/vladan-falcic-sqcap/](https://www.linkedin.com/in/vladan-falcic-sqcap/) * [https://www.linkedin.com/in/jelly-ji-7b193a177/](https://www.linkedin.com/in/jelly-ji-7b193a177/) * [https://www.linkedin.com/in/euglena-game/](https://www.linkedin.com/in/euglena-game/) - # Development Roadmap - ## Overview - - * Total Estimated Duration: 3 months * Full-time equivalent (FTE): 4 FTE * Total Costs: 12,000 DAI - ### **Milestone 1 —— Koi Metaverse NFT Modules and Assets** - - * Estimated Duration: 3 months * FTE: 4 FTE. * Costs: 12,000 DAI @@ -396,7 +307,7 @@ Hongfeng Liu 5. - smart contract: Fish Tank + smart contract: Fish Tank fish tank contract include: capacity, totalPower, fishList implemented by ink @@ -426,7 +337,7 @@ Hongfeng Liu - 8. + 8. Test @@ -435,25 +346,18 @@ Hongfeng Liu - ## Community Engagement - - * **Play to Earn:** Koi Metaverse will also adopt the P2E model to inspire players of GameFi games. Through P2E, players can share the growth and development dividend of the Koi Metaverse. * **Genesis Collection:** [Koi NFTs Genesis Collection Offering — Phase 1: Newborn](https://koimetaverse.medium.com/koi-nfts-genesis-collection-offering-phase-1-newborn-5619038200c6) Genesis Collection is an effective way to start a project and have public awareness. * **GameFi Communities:** Koi Metaverse will collaborate with game P2E communities, including Yield Guild Games (YGG), A16, etc. to complete users acquisition and users growth. - # Future Plans Our project plans to become a parachain for the Polkadot network, which provides benefits from shared security and communications (XCMP). We will launch our game application Koi Metaverse first to complete the first adoption and then open our infrastructure layer Koi Network to support more game Dapps. The Koi Network will support marketplace, NFT DeFi, GameFi Hub and Cross-chain Gateway, etc. - # Additional Information - - * Website: [https://koi.io/](https://koi.io/) (Previously [http://koi.network/](http://koi.network/)) * Twitter: [https://twitter.com/KoiMetaverse](https://twitter.com/KoiMetaverse) * Discord: [https://discord.gg/Aj5Zq9Cx9r](https://discord.gg/Aj5Zq9Cx9r) diff --git a/applications/Libra.md b/applications/Libra.md index c61d21c6193..bd558bc97f2 100644 --- a/applications/Libra.md +++ b/applications/Libra.md @@ -1,6 +1,5 @@ -# Project Libra +# Libra - Decentralized Payment Network -- **Project Name:** Libra - Decentralized Payment Network - **Team Name:** @Scale Technologies - **Payment Address:** 0x77AE9e7c90E6f6137AC3b3cd09A4bdc4654A0fe5 (ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 @@ -26,6 +25,7 @@ Resolvers Network leverages the power of blockchain and the community to resolve Libra bridges the gap between blockchain and eCommerce to enable all people to exchange value and transact globally, securely, at significantly lower cost, and more inclusively than traditional financial systems allow. ### Project Details + The project's scope is to build three core components that define the foundation of Libra Network: LRP protocol, Resolver Networks, and Javascript SDK. From these components, people can easily integrate the cryptocurrencies payment to their business while their customers are protected by Libra Network. #### LRP protocol @@ -34,10 +34,10 @@ LRP protocol allows buyer and seller to make a p2p payment while the cryptocurre ![Project Libra-LRP Protocol](https://user-images.githubusercontent.com/92568442/148349639-145690aa-98c3-4e13-b9a3-ccfa01d55f6a.png) - For the LRP protocol, the data model for LRP protocol should be generic and flexible for any use cases. Besides, it should be small to store on-chain but need to provide enough information if needed (e.g. dispute case). ##### Data model + ```json { "id": "uuid", @@ -52,6 +52,7 @@ For the LRP protocol, the data model for LRP protocol should be generic and flex "updated_at": 1640761504444 } ``` + ##### State transition ![state-transition](https://user-images.githubusercontent.com/92568442/148345661-fd24292a-389b-44ef-95a5-5d8422f546c6.png) @@ -69,9 +70,11 @@ This diagram shows the whole dispute process ![Project Libra- Dispute process](https://user-images.githubusercontent.com/92568442/148343813-2f581a72-36b7-4065-bf69-cb0d642f25f5.png) #### SDK + The SDK is indispensable for the product’s adoption. It should be developer-friendly and easy to integrate with a few lines of the code. The interface of the SDK is listed below. **Install** + ```bash npm install libra-sdk ``` @@ -81,17 +84,18 @@ import Libra from "@libra-sdk"; const libra = new Libra(config); ``` + **Checkout** Create a payment with the SDK ```jsx const payment = libra.createPayment({ - payee, - amount, - currency, - description, - receipt + payee, + amount, + currency, + description, + receipt }); ``` @@ -101,22 +105,23 @@ Cancel a payment (before the seller accept) libra.cancelPayment(payment.id) ``` -Complete a payment +Complete a payment ```jsx libra.complePayment(payment.id); ``` -Dispute a payment +Dispute a payment ```jsx libra.dispute({ - paymentId: payment.id, - evidence: {...} + paymentId: payment.id, + evidence: {...} }); libra.escalateDispute(disputeId); ``` + **Seller’s dashboard** Get payments @@ -153,11 +158,11 @@ Setup identity ```jsx libra.setIdentity({ - displayName, - legalName, - email, - website, - ... + displayName, + legalName, + email, + website, + ... }); ``` @@ -165,9 +170,9 @@ Apply resolver ```bash libra.apply({ - role: "resolver", - application: {...}, - deposit: 100000, + role: "resolver", + application: {...}, + deposit: 100000, }); ``` @@ -175,9 +180,9 @@ Nominate ```jsx libra.nominate({ - address, - amount, - ... + address, + amount, + ... }); ``` @@ -199,11 +204,11 @@ libra.rejectAppeal(disputeId); ### Ecosystem Fit -- **Where and how does your project fit into the ecosystem?** Libra is built on top of Substrate. Thanks to Substrate's ecosystem, Libra supports all substrate tokens as a payment method by default. +- **Where and how does your project fit into the ecosystem?** Libra is built on top of Substrate. Thanks to Substrate's ecosystem, Libra supports all substrate tokens as a payment method by default. - **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** Libra's target audience is sellers/buyers who want a safer, faster, more straightforward solution for online payment using cryptocurrencies. Through Resolvers Network, Libra also brings new jobs and a new way to earn income by solving disputes. -- **What need(s) does your project meet?** Libra provides a safe mechanism for both buyers and sellers to transact online -- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** As far as we know, Libra, with its unique LRP protocol and Resolvers network, is the first project designed to solve real-world eCommerce transactions. There are no similar projects in the ecosystem yet. +- **What need(s) does your project meet?** Libra provides a safe mechanism for both buyers and sellers to transact online +- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** As far as we know, Libra, with its unique LRP protocol and Resolvers network, is the first project designed to solve real-world eCommerce transactions. There are no similar projects in the ecosystem yet. ## Team :busts_in_silhouette: @@ -216,37 +221,40 @@ Libra's target audience is sellers/buyers who want a safer, faster, more straigh - **Contact Name:** Anthony Dong - **Contact Email:** anthony@atscale.xyz -- **Website:** https://atscale.xyz +- **Website:** ### Legal Structure + (We're in the process of registering the legal entity) + - **Registered Address:** N/A - **Registered Legal Entity:** N/A ### Team's experience -AtScale is a team specialized in blockchain development. We aim to rely on blockchain technologies to solve real-world problems and facilitate blockchain-based products to mass adoption. +AtScale is a team specialized in blockchain development. We aim to rely on blockchain technologies to solve real-world problems and facilitate blockchain-based products to mass adoption. -- **Anthony Dong**: Anthony successfully built and exited several internet startups during the last ten years. Anthony was the CTO in his recent company, helping the company bootstrapped from zero to $15 million ARR (Annual Recurring Revenue) in 2 years. +- **Anthony Dong**: Anthony successfully built and exited several internet startups during the last ten years. Anthony was the CTO in his recent company, helping the company bootstrapped from zero to $15 million ARR (Annual Recurring Revenue) in 2 years. - **Andrew Le**: Andrew was the Lead Researcher at his previous company, specializing in AI/Machine Learning and Blockchain technologies. He led the development to build one of the most accurate body measurement prediction engines in the industry during his past job. ### Team Code Repos -- https://github.com/atscaletech/ -- https://github.com/atscaletech/polkadot-hackathon-apac +- (AtScale Technologies) +- (Hackathon Submission) ### Team LinkedIn Profiles (if available) Due to privacy concerns, the team information will provide in private by email if requested. ## Development Status :open_book: + Libra is founded and developed in the Polkadot APAC Hackathon 2021. We already built a proof of concept application and here is our hackathon submission: -- Pitch video: https://youtu.be/pR4_2nrrJQQ -- Demo screencast: https://youtu.be/cR7gKSzVoAY -- Live demo: https://app.libra.atscale.xyz -- Explorer: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.libra.atscale.xyz#/explorer -- Git repository: https://github.com/atscaletech/polkadot-hackathon-apac +- Pitch video: +- Demo screencast: +- Live demo: +- Explorer: +- Git repository: ## Development Roadmap :nut_and_bolt: @@ -255,7 +263,7 @@ Libra is founded and developed in the Polkadot APAC Hackathon 2021. We already b - **Total Estimated Duration:** ~ 4 months - **Full-Time Equivalent (FTE):** 1.5 FTE - **Total Costs:** 16,000 USD - + ### Milestone 1 - LRP Protocol Implementation - **Estimated duration:** 1 month @@ -269,7 +277,7 @@ Libra is founded and developed in the Polkadot APAC Hackathon 2021. We already b | 0c. | Testing | All of the code will be covered by unit and integration test suites with the testing instruction. | | 0d. | Live testnet | The live testnet with a few nodes and public RPC endpoints to test or connect more nodes. | | 1. | Substrate module: LRP pallet | The LRP protocol implementation. | -| 2. | Substrate module: Currencies pallet | The extended module of ORML currencies allows creates and manages currencies by bonding some native tokens. | +| 2. | Substrate module: Currencies pallet | The extended module of ORML currencies allows creates and manages currencies by bonding some native tokens. | | 3. | Substrate based chain | The integration LRP protocol with substrate chain. | ### Milestone 2 - Resolvers Network Implementation @@ -314,12 +322,12 @@ In the short term, we plan to launch the validation and testing phase: - **Canary network launch:** At the end of this phase, we plan to join the Kusama para-chain auction and launch the canary network. For the long term plan, we will: + - Launch Polkadot para-chain - Acquire more users and boost the network's GMV (gross merchandise value) - Scale up the resolvers networks - Develop tools for Libra such as fraud payment detection, API, AI/ML dispute processor, ... - ## Additional Information :heavy_plus_sign: **How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/MAP-Bridge.md b/applications/MAP-Bridge.md index b5d7c2b637c..17fdb325f2b 100644 --- a/applications/MAP-Bridge.md +++ b/applications/MAP-Bridge.md @@ -1,5 +1,5 @@ -# Open Grant Proposal -* **Project:** Map Bridge +# Map Bridge + * **Proposer:** zcheng9 * **Payment Address:** 1CFM6QDvxwXEV3dUN9x2ftqq4rwAfkxN9W * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/89#issuecomment-792968983) diff --git a/applications/MIXER.md b/applications/MIXER.md index da578232c78..e7d61661dee 100644 --- a/applications/MIXER.md +++ b/applications/MIXER.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Webb Mixer -* **Project Name:** Webb Mixer * **Team Name:** Webb * **Payment Address:** 0xAC8E9305dc7AC95685c7D52E759c35aCd9eB90Ff diff --git a/applications/MIXERv2.md b/applications/MIXERv2.md index c971ee99af3..d21a4319829 100644 --- a/applications/MIXERv2.md +++ b/applications/MIXERv2.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Webb Mixer Extended -* **Project Name:** Webb Mixer Extended * **Team Name:** Webb * **Payment Address:** 0xAC8E9305dc7AC95685c7D52E759c35aCd9eB90Ff diff --git a/applications/Maki.md b/applications/Maki.md index 9f080d5b78f..7a14433bdea 100644 --- a/applications/Maki.md +++ b/applications/Maki.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Maki -- **Project Name:** Maki - **Team Name:** Cyril Carlier (Individual) - **Payment Address:** 0x7e575d2140aa4b723ac2014d5627330a7ed514d4 (ERC-20 USDC) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 diff --git a/applications/MangoBOX-Protocol.md b/applications/MangoBOX-Protocol.md index 2e8bad12479..566eee39af4 100644 --- a/applications/MangoBOX-Protocol.md +++ b/applications/MangoBOX-Protocol.md @@ -1,8 +1,5 @@ -# W3F Grant Proposal +# MangoBOX Protocol - - -- **Project Name:** MangoBOX Protocol - **Team Name:** MangoBOX labs - **Payment Address:** 0x33e69715988126eB3653bFAfd338320BE9A10cd0(USDC)) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Meta_Defender.md b/applications/Meta_Defender.md index c254a4b500c..84d08be5582 100644 --- a/applications/Meta_Defender.md +++ b/applications/Meta_Defender.md @@ -1,74 +1,73 @@ -# W3F Grant Proposal - -* **Project Name:** Meta Defender -* **Team Name:** Meta Defender Team -* **Payment Address:** 25r4oZedLXEunTmdvytyH4xcmQqqWWw8KmphdiD5LqpU29pv （aUSD） -* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 - - +# Meta Defender + +- **Team Name:** Meta Defender Team +- **Payment Address:** 25r4oZedLXEunTmdvytyH4xcmQqqWWw8KmphdiD5LqpU29pv （aUSD） +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + + ## Project Overview :page_facing_up: - + ### Overview - + Meta Defender is a decentralised insurance protocol built on the blockchain. It is developed with ink! smart contract, and is designed to provide insurance for transactional and non-transactional assets on the blockchain of users. Later on, it will support cross-chain insurance through substrate and XCM. In the meantime, Meta Defender is also working to apply blockchain technology to real-world insurance scenarios, becoming an important addition to the traditional insurance industry. This project is the first-place winner of Acala Hackathon and is in the 2022 cohort of Web3.0 Bootcamp supported by Web3.0 Foundation and Parity. - + The rapid development of Defi has led to a huge increase in the digital assets that are transactional in smart contracts, which also makes it very vulnerable to cyber attacks. Conventional insurances, on the other hand, have limited capacity to provide transparent, secured and rapid protection for precious assets. In order to cater for the increasing needs, our team decided to work on a Defi insurance protocol, also to solve several pain points in existing web3 insurance products. - -Meta Defender is planned to launch on the parachains in the Polkadot Ecosystem, designed to provide insurance services to multiple subject-matters in the Polkadot Ecosystem. - + +Meta Defender is planned to launch on the parachains in the Polkadot Ecosystem, designed to provide insurance services to multiple subject-matters in the Polkadot Ecosystem. + ### Project Details - + ### 1. Mockups/designs of any UI components - Homepage -

          1

          - +

          1

          + - Buy Cover -

          2

          - +

          2

          + - Become an underwriter -

          3

          - +

          3

          + ### 2. Project Technology Stacks - Rust - Substrate - Node.js - Ethers.js - + ### 3. MVP -

          +

          + +

          -

          - - Buy Cover Meta Defender uses stablecoins to insure, underwrite and pay out for claims. Each Meta Defender policy is currently valid for one year. The premium rate will be calculated using a customised AMM 2.0 model, which will be explained in detail in the next part. - + - Become an underwriter -Underwriters share the Rewards from each premium according to the weight of the capital they provide to the whole Capital Reserve. At the same time, the underwriting capital is correspondingly frozen until the policy expires. Until this policy expires, the underwriter can only withdraw the unfrozen portion of its own provided assets. - +Underwriters share the Rewards from each premium according to the weight of the capital they provide to the whole Capital Reserve. At the same time, the underwriting capital is correspondingly frozen until the policy expires. Until this policy expires, the underwriter can only withdraw the unfrozen portion of its own provided assets. + - Leveraged Mining The Meta Defender protocol makes secondary use of the underwriting capital, with 70% of the capital participating in the public chain's officially secured mining pool. 20% of the proceeds of Leveraged Mining will go to a Risk Reserve. - + - Risk Reserve When a claim occurs, priority is given to using the funds in the Risk Reserve to pay out; when there is not enough to pay out, the excess is shared among all underwriters according to the weighting of the capital in the Capital Reserve by the underwriters. In that way, returns for underwriters can be maximised and the risk of loss can be minimised. - + ### 4. Documentation of core components, protocols, architecture, etc. to be deployed For more detailed explaination, please check out our [white paper](https://metadefender.gitbook.io/meta-defender-v3-eng-ver./). - + #### 4.1 AMM 2.0 Model for calculating premium rates First, two concepts are defined, @@ -79,13 +78,13 @@ First, two concepts are defined, In the absence of new underwriters joining or no underwriters withdrawing liquidity, both of the above always satisfy as the followings: -

          +

          k is a fixed value. As the number of policies increases, P gradually decreases and α increases, representing an increase in insurance demand, and vice versa. When new underwriters join, P increases, α remains constant, and k increases accordingly. -

          +

          Similarly, when the underwriter withdraws liquidity, P and k decrease at the same time. @@ -93,18 +92,18 @@ If the policy expires and frozen capital is released, this also leads to an incr There is a minimum value of α as α0​, and the decrease of α is limited to this value, which then causes the value of k to increase. When the value of P "expands" to the point where α touches α0​, then α stops decreasing and k increases: -

          +

          In the traditional insurance industry, premiums are actuarially priced based on the probability of historical risk events. The existing blockchain insurance products also build some actuarial models, but it is difficult to ensure the actuarial results are truly objective and credible when the historical data samples are not sufficient. Meta Defender tends to determine the risk pricing of each agreement based on the most basic economic rule: the relations between supply and demand. -One possible question is whether the mechanism will cause underwriters to purchase their own insurance in bad faith and drive up premium rates. In order to avoid such attack, In order to calculate k, Meta Defender will add virtual liquidity to the real P value, which will make the curve of premium rate more smooth and significantly increase the cost of such attack. - +One possible question is whether the mechanism will cause underwriters to purchase their own insurance in bad faith and drive up premium rates. In order to avoid such attack, In order to calculate k, Meta Defender will add virtual liquidity to the real P value, which will make the curve of premium rate more smooth and significantly increase the cost of such attack. + #### 4.2 Rewards and responsibility of underwriters To facilitate valuation, Meta Defender suggests to use a stablecoin for insurance and underwriting purposes. Assuming the stablecoin is called Token, the underwriter provides A tokens(A as the number of the token) to an Capital Reserve and receives a number of sTokens (staked token) based on the capital exchange rate η of the pool. The number of sToken, which is A' is: -

          - +

          + The sToken is not a transferable ERC20 token; it is simply a credit to the underwriter by the pool as a credential to capture premium rewards and withdraw assets in the future. At the time each pool is created, the starting value of η is 1. Given that pay-outs of claims are prioritised through the Mining Pool balances for claims(Risk Reserve), the value of η is maintained at 1 as long as there is no large-scale claims event resulting in an encroachment on the Capital Reserve's principal. @@ -121,6 +120,7 @@ At the time each pool is created, the starting value of η is 1. Given that pay- #### 4.2.2 Data Structure of the Underwriter and the Policy When an underwriter stakes some Tokens to the protocol, the protocol marks him like this: + - index: the order in which the underwriter joined the protocol; - sTokenAmount: the number of sTokens acquired by the underwriter (i.e., A as the number of Token in the previous section); - rewardDebt（RDebt）: ​sTokenAmount∗accRPS, the reduction factor for calculating the underwriter's capture of the reward; @@ -134,37 +134,37 @@ When a policy is created, the protocol will mark it as follows： After a policy is generated, we set the amount paid by policyholder as “fee”, and we have -

          - +

          + For each underwriter in the underwriting Capital Reserve, the withdrawable proceeds at this point are calculated as: -

          +

          ​The proceeds can be immediately withdrawn to the underwriter's own wallet. - + #### 4.2.4 Policy Generation and Frozen Capital A policy is generated and the accSPS is increased: -

          +

          For each underwriter in the pool, the cumulative frozen capital amount is: -

          - +

          + #### 4.2.5 ​When the Risk Reserve is Insufficient to Pay for Claims -When the Risk Reserve does not have enough funds to pay for a policy that actually suffers a loss or damage, the protocol will share the excess of the claim amount with the underwriter according to the weight of the underwriter's sToken. +When the Risk Reserve does not have enough funds to pay for a policy that actually suffers a loss or damage, the protocol will share the excess of the claim amount with the underwriter according to the weight of the underwriter's sToken. -This is an extremely rare and exceptional circumstance and will result in a reduction of the exchange factor η. +This is an extremely rare and exceptional circumstance and will result in a reduction of the exchange factor η. Assume when that this situation arises, and the excess of claims over the Risk Reserve is δ, the new η becomes -

          +

          TokenRemain includes the token frozen in the protocol of the underwriters who are able to underwrite for new policies, as well as the token of those underwriters who have stopped underwriting for new policies. - + ​It can be seen that the value of η decreases further, and the number of sTokens - representing the weight of capturing premium rewards, while bearing liability - that can be obtained for an equal amount of Tokens for underwriters joining the pool thereafter is increased . This is clearly due to the reduction in the actual underwriting capacity of the original underwriters following the erosion of the principal in the pool. - + #### 4.3 Underwritten Assets Withdrawal Mechanism #### 4.3.1 Available Assets that can be Withdrawn by Underwriters @@ -172,21 +172,21 @@ TokenRemain includes the token frozen in the protocol of the underwriters who ar Underwriters can withdraw a portion of their unfrozen capital at any time before it is completely frozen. However, the frozen part needs to wait for the corresponding policy expiration to exit. The assets that can be withdrawn by the underwriter is calculated by the formula: -

          - +

          + ​shadow is the amount of assets of the underwriters that has been frozen. However, the situation becomes more complicated when considering a policy that has expired which results in releasing part of frozen capital. - + #### 4.3.2 Cancellation of Policies Along with the cancellation of policies which expire, the corresponding underwriters’ frozen capital should be released. When a policy is generated, we record its lastProviderIndex and ΔaccSPS. When it is cancelled, the protocol synchronises the latestUnfrozenIndex to the lastProviderIndex of this policy, and accumulates accSPSDown: -

          - +

          + ​When calculating an underwriter's shadow, it is necessary to first determine the relationship between his index and latestUnfrozenIndex. When index<=latestUnfrozenIndex, it means that the capital being released already has the part of the underwriter’s frozen capital. His shadow will be calculated by: -

          - +

          + #### 4.3.3 After Underwriter Withdrawal of Assets In order to make the protocol easier to maintain and to reduce the cost of gas fee when users invoke the contract, Meta Defender currently requires the underwriter who would like to quit to withdraw all remaining liquidity at once (i.e., withdraw mentioned above). @@ -194,7 +194,7 @@ In order to make the protocol easier to maintain and to reduce the cost of gas f Of course, you may only want to "withdraw partially". It is very simple to implement this - you could simply withdraw in full and then re-join with your desired coverage amount. This saves the protocol from having to maintain a huge ledger, where the cost of gas would otherwise become unimaginable. When an underwriter withdraws assets, he or she needs to destroy all of his or her sToken. - + Suppose an underwriter P destroys all of his sToken, declaring that he has ended his status as an underwriter. Regardless of how much capital he has actually withdrawn (usually less than his original provided capital, i.e. η*sTokenAmount, less than ), he can no longer continue to capture premium and no longer underwrite new policies, i.e., no longer "capture" new shadow. The protocol creates a "historical identity" for him, P', and records the following parameters: @@ -208,14 +208,14 @@ index: the index inherited from P; sTokenAmount_P : the sTokenAmount inherited from P; SDebt_P: the sDebt inherited from P. - + It can be seen that the maximum amount that can eventually be released by P' is: η∗fsToken​ ------ ①; The shadow inherited by P' from P is: -sTokenAmount_P*accSPS_P - SDebt_P +sTokenAmount_P*accSPS_P - SDebt_P Or @@ -230,7 +230,7 @@ When ② < ①, the difference between ① and ② is the capital of P being unf As accSPSDown increases, the value of ② eventually goes to zero. Zero is the minimum value of ② and cannot be a negative number. After ① goes to zero, all residual capital of P finishes withdrawing. - + #### 4.4 Leveraged Liquidity Mining Rewards Mechanism The holder of sToken, i.e. the underwriter of Meta Defender, is entitled to the Leveraged Liquidity Mining rewards. @@ -238,12 +238,12 @@ The holder of sToken, i.e. the underwriter of Meta Defender, is entitled to the In order to encourage underwriters to provide long-term, stable capital, sToken holders are required to hold their sTokens for a certain period of time (approximately 14 natural days, with minor variations depending on the speed of block creation on the mainnet) before they can participate in the withdrawal of this Rewards. After withdrawing from the Capital Reserve and destroying the sToken, the holder will lose the eligibility to withdraw the proceeds. The mining proceeds will be hosted separately by Meta Defender's governance contract and will be claimed from the pool for sToken. - - - - + + + + ### Ecosystem Fit - + - Where and how does your project fit into the ecosystem? Meta Defender will use the stablecoin in parachains as the currency for buying cover, underwriting and for payouts of claims. Currently Meta Defender is planned to be deployed with ink! Smart contract and compatible with Substrate and XCM. Ultimately, we would like to provide insurance services to the main parachains and major protocols in the Polkadot Ecosystem. Also, by introducing XCM, we would like to achieve cross-chain insurance. @@ -269,59 +269,61 @@ Meta Defender’s pricing model is an upgraded Automated Market Maker Model pure Meta Defender’s Leveraged Mining will cooperate with Liquidity Mining protocols in the ecosystem while Nsure has their own capital mining pool. We believe, cooperating with top Liquidity Mining protocols in the ecosystem will maximise the returns with the capital that underwriters inject to the protocol. We are also planning to provide insurance service for more off-chain scenarios by integrating blockchain oracles, such as flight cancellation insurance. - + ## Team :busts_in_silhouette: - + ### Team members - + - Name of team leader: Alvin, CEO - Names of team members: Angie, Fullstack Engineer & 0xdeadbeef, Fullstack Engineer - + ### Contact - + - **Contact Name:** Alvin Lu - **Contact Email:** 0xhikarilab@gmail.com - **Website:** metadefender.finance - + ### Legal Structure - + - **Registered Address:** N/A - **Registered Legal Entity:** N/A - + ### Team's experience - + Alvin: With a background in financial investing and insurance consulting, as well as working a Tech Lead in a Venture Capital, Alvin brings his varied experience to Meta Defender. Alvin is also the external consultant for two AI based projects of China Life Insurance Company, namely an operational decision making tool and a fraud detection technology. He also has massive experience in blockchain, by constructing a DEX and IDO platform. He would like to integrate his expertise in Web3.0 with knowledge in insurance industry and provide a better solution to Blockchain insurance. - + Angie: Angie is a Data Scientist in a ASX-listed Fintech in Australia. She has extensive experience in Finance industry since 2017 and has profound understanding regarding tech utilization in finance industry. Using her expertise, she co-designed the pricing model and business flow of Meta Defender. She is also a crypto enthusiast and fascinated by She masters Solidity, Python Vue.js and Node.js. - + 0xdeadbeef: He is a web3.0 coder and researcher for more than 4 years. He has a master's degree from Shanghai Jiaotong University and a major in finance. He masters solidity, Golang, Rust, Python, and Nodejs. In his past working experience, he worked for a public chain company and researched and developed on-chain DeFi projects, especially in options markets. He has much experience in EVM compatible blockchains. Recently, he has been passionate about insurance, which may be a new area in DeFi. Through his working experience in the on-chain option market, he considered there are many similarities between options and insurance. - + ### Team Code Repos - + **Team Repo** + - https://github.com/Meta-Defender/ - https://github.com/Meta-Defender/Meta-Defender-Contract-V3 - - + + **Team Member** + - https://github.com/lutianzhou001 - https://github.com/327istesting - https://github.com/Angie-Sheng - + ## Development Roadmap :nut_and_bolt: - + ### Overview - + - **Total Estimated Duration:** 8 months - **Full-Time Equivalent (FTE):** 2 - **Total Costs:** 8,000 USD - + ### Milestone 1 — Basic Functionalities - + - **Estimated Duration:** 4 months - **FTE:** 2 - **Costs:** 4,000 USD - + | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | @@ -329,14 +331,14 @@ Angie: Angie is a Data Scientist in a ASX-listed Fintech in Australia. She has e | 0c. | Testing Guide | Core functions will be covered by unit tests, along with detailed explanation step by step. | | 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | | 1. | ink! smart contract | An ink! smart contract that will enable the digital assets holders to buy cover and the capital holder to become an underwriter. | -| 2. | Manual of interaction between ink! and front-end | We will provide a manual regarding constructing an interface for the interaction between front-end and ink! smart contract & Polkadot.js wallet, just like what web3.js and ethers.js have done in the EVM ecosystem. | - +| 2. | Manual of interaction between ink! and front-end | We will provide a manual regarding constructing an interface for the interaction between front-end and ink! smart contract & Polkadot.js wallet, just like what web3.js and ethers.js have done in the EVM ecosystem. | + ### Milestone 2 Substrate + XCM - + - **Estimated Duration:** 4 months - **FTE:** 2 - **Costs:** 4,000 USD - + | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | @@ -345,22 +347,22 @@ Angie: Angie is a Data Scientist in a ASX-listed Fintech in Australia. She has e | 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | | 0e. | Article | We will publish an **article** that explains the functionalities Meta Defender provides, which will cover: 1. auto-pricing model; 2. economic model of insuring and underwriting; 3. how we achieve cross-chain insurance through substrate and XCM and open source this part of code. | | 1. | Cross-chain support | Establish a local parachain testnet and two local parachains A and B with sovereign account in each other. With smart contract deployed on A parachain, allow the user to buy cover and receive his claim from addresses on the B parachain through XCM. | - - + + ## Future Plans - + Short-term plan: Expand the subject-matter insured. We plan to provide insurance on at least five parachains and/or products running on them in the Polkadot Ecosystem. - + Medium-term plan: With the aid of blockchain oracles function, to cover real-life off-chain cases. A potential use case can be flight cancellation insurance. - -Long-term: We would like to cooperate with professional security service providers and to undertake detailed risk analysis on the subject-matter insured and potential projects, which enables us to issue security rating reports and become the security rating agency in web3.0 realm. - + +Long-term: We would like to cooperate with professional security service providers and to undertake detailed risk analysis on the subject-matter insured and potential projects, which enables us to issue security rating reports and become the security rating agency in web3.0 realm. + ## Additional Information :heavy_plus_sign: - -**How did you hear about the Grants Program?** - + +**How did you hear about the Grants Program?** + Meta Defender is the first-place winner of Acala Hackathon: https://twitter.com/AcalaNetwork/status/1527290444379394049?s=20&t=u60vX2VZTWvSoZ1x62Y-sA -Meta Defender is also in the 2022 cohort of Web3.0 Bootcamp supported by Web3 Foundation, Parity and Wanxiang Blockchain Labs. +Meta Defender is also in the 2022 cohort of Web3.0 Bootcamp supported by Web3 Foundation, Parity and Wanxiang Blockchain Labs. Since we have participated in a few activities in the Polkadot Ecosystem and have a profound understanding of the eco, we have been advised that we could apply for the grants program and grow with Polkadot. diff --git a/applications/NFTStore_Network.md b/applications/NFTStore_Network.md index e9dddd1eceb..3fdda9ec848 100644 --- a/applications/NFTStore_Network.md +++ b/applications/NFTStore_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# NFTStore -* **Project:** NFTStore * **Proposer:** [NFTT Studio](https://github.com/NFTT-studio) * **Payment Address:** 1AeR4htoGwDRMpw7S2TTrzjJxeGLZsopiE diff --git a/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md b/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md index a9dbef69d15..ece5ba07b63 100644 --- a/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md +++ b/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Protocol for NFT Migration and Data Exchange -* **Project Name:** Protocol for NFT Migration and Data Exchange * **Team Name:** Perpetual Altruism * **Payment Address:** BTC : 1B6AHziiBvE28Lg74n23V3dYXbxcVLGKYi diff --git a/applications/Nolik.md b/applications/Nolik.md index f2bf354d117..4c84a0e8a83 100644 --- a/applications/Nolik.md +++ b/applications/Nolik.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Nolik -- **Project Name: Nolik - **Team Name: Chainify - **Payment Address:** 0x9aD97d8605F80003106B0ED7DEe330F064674365 (USDT) - **Level: 1 @@ -8,6 +7,7 @@ ## Project Overview :page_facing_up: ### Overview + Nolik is a protocol for delivering digital content for web 3.0. It allows developers to create applications for formal communication that connect people without any form of censorship or third-party control. The protocol design is based on the ServiceLess approach, meaning that no services from third parties are needed for users to communicate. @@ -18,22 +18,22 @@ Blockchain logic will allow users to create programmable messages rules so they For example, users will be able to create a white list (or black list) of senders which will protect them from spam or irrelevant conversations. Another example would be creating rules like accepting messages within a particular block range or if a particular token is attached to the message, etc. - ### Project Details #### The problem we are targeting + The name Nolik stands for No Leak. -We believe that privacy is a fundamental right of every person and we believe that it should be protected. +We believe that privacy is a fundamental right of every person and we believe that it should be protected. Unlike privacy-first messaging applications like Signal or Threema, we offer a tool that allows communication without a need to trust an app itself. It also allows communication without a permission of a third-party which creates a great foundation on which users can rely and build their tools on top of this ecosystem. - #### Technology overview -Nolik uses a combination of blockchain and IPFS technologies. + +Nolik uses a combination of blockchain and IPFS technologies. The user generates an IPFS file with a particular structure on a client-side and broadcasts it to the blockchain network with additional metadata. In addition to required information about the transaction (like signature, sender, recipient, etc.) we provide additional information about the message. We split the blockchain level and messages level by creating a separate set of encryption keys. -Blockchain (identity) keypairs stand for token management and messages (accounts) keypairs stand for message encryption. +Blockchain (identity) keypairs stand for token management and messages (accounts) keypairs stand for message encryption. Users can have several identities (like personal or corporate). At the same time, each identity can have multiple accounts (like email addresses). Each message is encrypted with a public key of the recipient. @@ -43,6 +43,7 @@ You can find how the protocol works in detail below. The protocol is flexible and allows the creation of various data structures which can fit the needs of any app. #### Use case example + Nolik protocol could be used for a media service that protects journalists and whistleblowers from political oppression and technological borders like firewalls, blockings, etc. The protocol guarantees the delivery of the message through the network due to the absence of a single point of failure. A freedom of speech which is guaranteed mathematically. @@ -51,7 +52,7 @@ This means that behind every post there is nothing but a public key. The journalist can prove his identity by publicly attaching the public key to his identity (for example, in social media) and signing some sample data. But if a journalist or a whistleblower would like to hide their identity nothing will stop him from doing that. By default every message is encrypted. -It sounds great but there is a potential scalability downside. +It sounds great but there is a potential scalability downside. To deliver the message to a million people the journalist will have to encrypt the same message million times. The journalist can create a separate account which stands for a channel. That account is a proxy that delivers the message to the audience. @@ -63,29 +64,28 @@ On the channel creation stage, the journalist can add a rule that the channel ac This approach allows them to deliver the message to an unlimited audience and save tons of resources. The same method can be used for creating private or public group conversations. - #### The Protocol Nolik protocol is designed to make trustless communication possible. It provides flexibility for developers so they can build their applications on top of the platform. The protocol allows to: -* Stay protected from a middleware attack -* Communicate without servers or service as a third-party -* Protect messages from unauthorized access with decentralized end-to-end encryption -* Guarantee that the message was sent at a particular date and time -* Have a provable immutability of message content, metadata, and the timestamp information -* Prove that the message was sent by a particular sender -* Prove that the message was sent to a particular recipient or recipients -* Make sure that all recipients received the same message at the same time -* Send messages from multiple senders at the same time -* Verify the sender and be protected from a phishing attack -* Attach tokens (like NFTs) to message -* Use different clients to get access to messages +- Stay protected from a middleware attack +- Communicate without servers or service as a third-party +- Protect messages from unauthorized access with decentralized end-to-end encryption +- Guarantee that the message was sent at a particular date and time +- Have a provable immutability of message content, metadata, and the timestamp information +- Prove that the message was sent by a particular sender +- Prove that the message was sent to a particular recipient or recipients +- Make sure that all recipients received the same message at the same time +- Send messages from multiple senders at the same time +- Verify the sender and be protected from a phishing attack +- Attach tokens (like NFTs) to message +- Use different clients to get access to messages Each message contains two main parts - the transaction data and the IPFS data. The transaction data is additional information that is sent along with required information within a transaction body. -It contains general metadata about the sender and recipient or recipients of the message. +It contains general metadata about the sender and recipient or recipients of the message. This information has a specific purpose and requires specific fields to be provided. The metadata is validated and checked at a sending stage and if something is wrong will be rejected by miners. @@ -99,7 +99,8 @@ However, to solve this issue users within a community can create services that c Another great way to solve this issue would be using FileCoin or similar services to make sure that the recipient will get the message in a longer period. #### Encryption -The message encryption is based on the Diffie-Hellman protocol with the ed25519 curve. + +The message encryption is based on the Diffie-Hellman protocol with the ed25519 curve. To encrypt the message the sender generates a shared secret with the recipient's public key and her private key. At the same time, the recipient generates the same shared secret with the sender's public key and his private key. There is no problem with decrypting the message if the recipient knows the sender's public key. @@ -111,7 +112,7 @@ To do that we use a trick with one-time-use nonce and sender's public key which They are required for the recipient, so he can decrypt the real sender's (sender's) public key and decrypt the message. We will dive into details below. -#### The transaction metadata +#### The transaction metadata Each message contains a specific set of information that is included in the blockchain transaction body. On the other side, recipient or recipients will be able to track the blockchain transactions and decrypt those which were sent to them. @@ -147,19 +148,20 @@ batch: ``` ##### Batch + --- -Each message is encrypted with the recipient's public key based on Diffie-Hellman protocol. +Each message is encrypted with the recipient's public key based on Diffie-Hellman protocol. If there are several recipients the same message is encrypted several times for different recipients. All the versions of the same message should be provided in the batch section. The message should contain nonce, sender, recipient, and data sections. **Nonce** is a section with a one-time generated 24-bit value. It allows making sure that the same message (like "Hi") can not be brute-forced by a malicious third party. -There are two nonce values - the private (encrypted) and the one-time-use one. +There are two nonce values - the private (encrypted) and the one-time-use one. As we mentioned earlier the message is encrypted with the sender's real public key, but for security reasons we encrypt it. -One-time-use nonce is used along with one-time-use public key to encrypt sender's real public key. +One-time-use nonce is used along with one-time-use public key to encrypt sender's real public key. -**Sender** is a section with information about the sender of a particular message. +**Sender** is a section with information about the sender of a particular message. It contains the encrypted public key of a sender. The one-time-use public key is required for the recipient, so he could decrypt the sender's real public key. @@ -175,6 +177,7 @@ It contains encrypted public keys of a recipient. The structure of that file is described below. ##### Nonce + --- The **onetimeuse** value is a one-time public 24-bit nonce that is generated on transaction creation. It is used as salt to sender->ciphertext, sender->blake2hash, verifier->ciphertext, verifier->blake2hash and recipient->blake2hash fields. @@ -186,8 +189,8 @@ It could be used for salting sender->blake2hash, verifier->blake2hash and recipi The **blake2hash** value is salted with the nonce blake2 hash of the nonce. Every recipient will have a unique nonce that can be used to prove message metadata and the content of the message independently from other recipients. - ##### Sender + --- **Sender** is a 32-bit string that represents the sender's public key and account address at the same time. @@ -204,9 +207,11 @@ It can be decrypted only by the recipient. The **blake2hash** value is a hashed sender's public key salted with a one-time-use nonce blake2 hash. The formula looks like this: + ``` H(H(pk), N) ``` + Where "H" is a blake2 hash function, "pk" is the sender's public key and N is a one-time nonce. The sender knows his public keys, and that allows to identify related messages among others. The downside of this approach is that once one knows the sender's public key he will be able to track the account activity. @@ -214,9 +219,11 @@ To fix this the one-time-use nonce can be replaced with private nonce, but in th List of **signatures** is a set of cryptographic proofs (digital signatures) of sender and one-time use private key. Both of the signatures sign the hash of all hashes according to the formula: + ``` H(nH | sH | v(0)H...v(n)H | rH | dH) ``` + Where "H" is a blake 2 hash function, "nH" is nonce blake2hash value, "sH" is sender's blake2hash value, "v(0)H...v(n)H" are concatenated verifiers' blake2hash values, "rH" is recipient's blake2hash value, "dH" is IPFS file hash. ##### Verifiers @@ -236,9 +243,11 @@ It can be decrypted only by the recipient. The **blake2hash** value is salted with one-time-use nonce blake2 hash of a hashed verifier's public key. The formula looks like this: + ``` H(H(pk), N) ``` + Where "H" is a blake2 hash function, "pk" is the verifier's public key and N is a one-time-use nonce. Verifier knows his public keys, and that allows to identify related messages among others. The downside of this approach is that once one knows the sender's public key he will be able to track the account activity. @@ -246,13 +255,15 @@ To fix this the one-time-use nonce can be replaced with private nonce, but in th List of **signatures** is a set of cryptographic proofs (digital signatures) of each verifier and one-time-use public key. Both of the signatures sign the hash of all hashes according to the formula: + ``` H(nH | sH | v(0)H...v(n)H | rH | dH) ``` -Where "H" is a blake 2 hash function, "nH" is nonce blake2hash value, "sH" is sender's blake2hash value, "v(0)H...v(n)H" are concatenated verifiers' blake2hash values, "rH" is recipient's blake2hash value, "dH" is IPFS file hash. +Where "H" is a blake 2 hash function, "nH" is nonce blake2hash value, "sH" is sender's blake2hash value, "v(0)H...v(n)H" are concatenated verifiers' blake2hash values, "rH" is recipient's blake2hash value, "dH" is IPFS file hash. ##### Recipient + --- **Recipient** is a 32-bit string that represents the recipient's public key and account address at the same time. @@ -262,22 +273,24 @@ It can be decrypted only by sender and recipient. The **blake2hash** vvalue is a blake2 hash of a hashed recipient's public key salted with one-time-use nonce. The formula looks like this: + ``` H(H(pk), N) ``` + Where "H" is a blake2 hash function, "pk" is the recipient's public key and N is a one-time-use nonce. The recipient knows his public keys, and that allows to identify related messages among others. The downside of this approach is that once one knows the recipient's public key he will be able to track the account activity. To fix this the one-time-use nonce can be replaced with private nonce, but in this case, the recipient will have to decrypt every message in the blockchain. - ##### Data + --- Data is a section with an IPFS hash of a file that contains encrypted message information in key-value format. We will discuss the structure of an IPFS file below. - #### The IPFS data file + --- The data file is a text file with a specific data structure. It contains encrypted data which can be decrypted only by the sender and recipient of a message. @@ -297,16 +310,16 @@ data: ``` #### Key + --- -The **ciphertext** value is an encrypted name of a particular field. +The **ciphertext** value is an encrypted name of a particular field. It can be decrypted only by sender and recipient. The **blake2hash** value is salted with the private nonce blake2 hash of data content. - #### PoC and prior work -We have been working on decentralized messaging apps for the last several years. +We have been working on decentralized messaging apps for the last several years. During this time the protocol became much more solid and stable. Here are some related links: @@ -317,12 +330,11 @@ Here are some related links: This is the latest open-source version of the messenger. The protocol is more or less the same, but to run the messaging service one has to use centralized servers to increase the user experience. - The **latest** version I've been working on is not open-source because it was a custom build for an external company, but here is a video demo of how the messenger works: >[XYZ Messenger Demo (EN) -- 5m 38s](https://youtu.be/HSMjikDiheY) -This technology has been used in production at a nonprofit organization [HelpTeens](https://helpteens.ru) in Saint-Petersburg that provides free online psychological support for teenagers. +This technology has been used in production at a nonprofit organization [HelpTeens](https://helpteens.ru) in Saint-Petersburg that provides free online psychological support for teenagers. We used Nolik to protect kids' privacy and keep their secrets safe. It worked perfectly, but we had to stop using the technology due to legal restrictions. A new set of legal rules obligates any company to disclose the decryption keys to authorities and we had nothing to disclose. @@ -350,7 +362,7 @@ The technology has changed but the core principles are still the same. >[Nolik DB Demo -- 1m 11s](https://youtu.be/PyueRPY4fHc) This is an experiment from one of the hackathons. -I applied the Nolik protocol to build a decentralized database that allows the storage of structured data using SQL syntax. +I applied the Nolik protocol to build a decentralized database that allows the storage of structured data using SQL syntax. #### Non-goals @@ -364,7 +376,6 @@ Although Nolik is designed to be an independent product, the secure platform wit For example, apps will be able to exchange secrets like private keys, send tokens or a WASM code. That might be one of the possible benefits for the Polkadot community, but we will know if there is any value only by talking to users. - ## Team :busts_in_silhouette: ### Team members @@ -377,14 +388,15 @@ That might be one of the possible benefits for the Polkadot community, but we wi - **Contact Email:** aboziev@gmail.com ### Legal Structure + No legal entity yet ### Team's experience -#### Amir Boziev +#### Amir Boziev Since 2018 I've been involved in various projects in different domains including edTech, private messaging, data security, social good, and others. -I've increased my expertise in product development, marketing, and programming. +I've increased my expertise in product development, marketing, and programming. Worked as a researcher in blockchain tech to find a product-market-fit for this amazing technology which I'm passionate about. For the last five years, I've been learning how to make successful products. @@ -393,8 +405,8 @@ One of them is growing. Right now I am learning [Game Thinking Mechanicks](http://gamethinking.io) to make better products. Previously worked as a Director of blockchain products and strategy at Latoken. -I've been working with amazingly talented people on product management and the development of both decentralized and centralized crypto exchanges. -We also have been working on fundamental research and development of a framework that simulates the behavior of a blockchain on a network level. +I've been working with amazingly talented people on product management and the development of both decentralized and centralized crypto exchanges. +We also have been working on fundamental research and development of a framework that simulates the behavior of a blockchain on a network level. We've analyzed the most popular consensus algorithms (PoW, PoS, dPoS BFT, etc.) and blockchain platforms (Bitcoin, Ethereum, Cordana, Ripple, Waves, Hashgraph, etc.). @@ -405,26 +417,25 @@ Rust experience: 3+ months, but moving fast. ### Team Code Repos -- https://github.com/chainify -- https://github.com/chainify/nolik +- +- Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. -- https://github.com/amrbz +- ### Team LinkedIn Profiles -- https://www.linkedin.com/in/amrbz +- ## Development Status :open_book: -* [XYZ Messenger](https://docs.google.com/document/d/1Vxieh7b6wTQZoHpBQQTC5bH58kwcYlF0wm8yh0acXCI/edit?usp=sharing) +- [XYZ Messenger](https://docs.google.com/document/d/1Vxieh7b6wTQZoHpBQQTC5bH58kwcYlF0wm8yh0acXCI/edit?usp=sharing) -* [Rhizome](https://docs.google.com/document/d/1nbqO-ZHKTltqS7a10MYHKIetiFPd_NS6danfV7rGp1I/edit?usp=sharing) +- [Rhizome](https://docs.google.com/document/d/1nbqO-ZHKTltqS7a10MYHKIetiFPd_NS6danfV7rGp1I/edit?usp=sharing) Those are research documents that lead me to this project. - ## Development Roadmap :nut_and_bolt: ### Overview @@ -451,7 +462,6 @@ This milestone will allow the operation of a local dev chain. | 2. | Substrate module: Message Validation | We will create a Substrate module that will validate the message on sending stage to accept or reject it | | 3. | Substrate chain | Both modules of our custom chain will allow users to set up account rules and validate incoming messages on whether the senders have a right to send a message or not. In case of a rejected transaction user will get a related error message| - ### Milestone 2 — Develop CLI tools This milestone will allow the usage of CLI tools, which are going to be written in Rust language. They will allow users to interact with the network by composing, sending, and accepting messages. @@ -472,27 +482,25 @@ This milestone will allow the usage of CLI tools, which are going to be written | 3. | CLI: get | We will create a CLI tool that will allow to download and read received messages if any | | 4. | CLI | CLI tools will allow users to compose messages, send them to recipients and read incoming messages on request | - ## Future Plans ### Short-term -* Apply to the Substrate Builders Program. -* Develop the PoC blockchain core with CLI tools -* Make customer research and validate product ideas -* Launch a public testnet and build a Messaging app - +- Apply to the Substrate Builders Program. +- Develop the PoC blockchain core with CLI tools +- Make customer research and validate product ideas +- Launch a public testnet and build a Messaging app ### Long-term -* Close seed funding round and form a team -* Apply to W3F L3 grant program -* Convert to mainnet -* Build a messaging app +* Close seed funding round and form a team +- Apply to W3F L3 grant program +- Convert to mainnet +- Build a messaging app ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** Personal recommendation of my friends: -* https://github.com/kmadorin -* https://github.com/CryptoBadBoy W3F grant program alumni (Fratcapp) \ No newline at end of file +- +- W3F grant program alumni (Fratcapp) diff --git a/applications/NuLink.md b/applications/NuLink.md index bf1386cd788..baeb8de311d 100644 --- a/applications/NuLink.md +++ b/applications/NuLink.md @@ -1,5 +1,5 @@ -# Open Grant Proposal -* **Project:** NuLink +# NuLink + * **Proposer:** Pawn * **Payment Address:** 0xf7410438ead9e89EEd5ca6e61a11E862C297ca0e diff --git a/applications/OpenSquare-offchain-voting.md b/applications/OpenSquare-offchain-voting.md index 3204ce6c7f6..97a6042872b 100644 --- a/applications/OpenSquare-offchain-voting.md +++ b/applications/OpenSquare-offchain-voting.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# OpenSquare off-chain voting for Polkadot ecosystem -* **Project Name:** OpenSquare off-chain voting for Polkadot ecosystem * **Team Name:** OpenSquare * **Payment Address:** 0x4905083abdD13bd95345A871701Fd0b08AbD46d1 (USDT) @@ -11,45 +10,48 @@ In short, you can see this proposed platform as [snapshot](https://snapshot.org) in the polkadot ecosystem. Though Polkadot/Kusama and most other Substrate based chains have on-chain governance and runtime can be easily upgraded with democracy. We think this platform still make sense with following reasons: -- Compared to the formal on-chain votes, this platform provides not so formal off-chain signed polls which may help token holders and community members engage **more** in the ecosystem building. -- Compared to Polkassembly polls on post: - - users have to sign their votes and the signed data will be stored on IPFS - - users don’t have to do any registration. - - Different strategies can also be provided to calculate the final result, rather than simply count the vote numbers. -- Not all on-chain systems with assets on Substrate based chains can upgrade with democracy, like assets issued on Statemine, ERC-20 assets which may be issued on Moonriver, Karura, Shiden, etc. +* Compared to the formal on-chain votes, this platform provides not so formal off-chain signed polls which may help token holders and community members engage **more** in the ecosystem building. +* Compared to Polkassembly polls on post: + * users have to sign their votes and the signed data will be stored on IPFS + * users don’t have to do any registration. + * Different strategies can also be provided to calculate the final result, rather than simply count the vote numbers. +* Not all on-chain systems with assets on Substrate based chains can upgrade with democracy, like assets issued on Statemine, ERC-20 assets which may be issued on Moonriver, Karura, Shiden, etc. ### Project Details + Off-chain votes will be an important part of OpenSquare collaboration platform. Other planned collaboration forms include bounties, payment QA, short term employment, etc. Key components in this proposal include: -- Predefined spaces where users can create proposals. It will definitely include Kusama and Polkadot, current para-chains with very high possibility. -- Proposal list in one space where users can view the closed or ongoing proposals. -- Proposal detail page where users can view the detail and the signed votes. -- A proposal discussion arena where users submit the signed messages and here we expect chaos. -- An authoring page where users can create proposals, and set the corresponding snapshot height, start and end date(height). -- Archive nodes interaction with which we read users’ balances on the corresponding snapshot block height. -- A backed server to interact with the node(Polkadot, Kusama, etc), store the organized data to DB, handle IPFS storage, provide APIs to get data. +* Predefined spaces where users can create proposals. It will definitely include Kusama and Polkadot, current para-chains with very high possibility. +* Proposal list in one space where users can view the closed or ongoing proposals. +* Proposal detail page where users can view the detail and the signed votes. +* A proposal discussion arena where users submit the signed messages and here we expect chaos. +* An authoring page where users can create proposals, and set the corresponding snapshot height, start and end date(height). +* Archive nodes interaction with which we read users’ balances on the corresponding snapshot block height. +* A backed server to interact with the node(Polkadot, Kusama, etc), store the organized data to DB, handle IPFS storage, provide APIs to get data. ![os_grant_voting](https://user-images.githubusercontent.com/2264908/127607269-5d54f0b0-d8b8-48f1-9c7a-fc8c205bc645.png) Some implementation notes: -- We have to call polkadot.js extension to sign the voting/poll, and some discussion messages. -- About voting power, since Polkadot/Kusama have proxy accounts, so we have to support proxy account vote on behalf of the original one. -- In this proposal, we will implement `balance of account` and `quadratic balance of account` strategies for Polkadot and Kusama. It means if Alice's balance is 100 at one chain height, her voting power will be 100 and 10 by these 2 strategies. -- We have a partnership with [Crust](https://crust.network/), and we may store data to IPFS through [decoo](https://decoo.io/) that crust granted. +* We have to call polkadot.js extension to sign the voting/poll, and some discussion messages. +* About voting power, since Polkadot/Kusama have proxy accounts, so we have to support proxy account vote on behalf of the original one. +* In this proposal, we will implement `balance of account` and `quadratic balance of account` strategies for Polkadot and Kusama. It means if Alice's balance is 100 at one chain height, her voting power will be 100 and 10 by these 2 strategies. +* We have a partnership with [Crust](https://crust.network/), and we may store data to IPFS through [decoo](https://decoo.io/) that crust granted. ### Ecosystem Fit + - Providing off-chain voting/polls to help token holders/community members engage more in ecosystem building. -- Flexible strategies help produce different voting/poll results which bring us different opinions from the on-chain tallying methods. -- [snapshot](https://snapshot.org) is popular for Ethereum stack projects, mainly for governance, and currently we didn't see similar projects in Polkadot ecosystem. +* Flexible strategies help produce different voting/poll results which bring us different opinions from the on-chain tallying methods. +* [snapshot](https://snapshot.org) is popular for Ethereum stack projects, mainly for governance, and currently we didn't see similar projects in Polkadot ecosystem. ## Team :busts_in_silhouette: ### Team members + - Yongfeng Li(@wliyongfeng), Full stack developer -- Chaojun Huang(@hyifeng), Full stack developer -- Wentao Chen(@qiyisi), Full stack developer -- Yizhou Xin(@YoshiyukiSakura), Full stack developer -- Alcazar(@Popoulosss), Designer -- Yaping Wu, BD and execution member +* Chaojun Huang(@hyifeng), Full stack developer +* Wentao Chen(@qiyisi), Full stack developer +* Yizhou Xin(@YoshiyukiSakura), Full stack developer +* Alcazar(@Popoulosss), Designer +* Yaping Wu, BD and execution member You can see our team with this [link](https://www.opensquare.network/team/). @@ -57,31 +59,32 @@ You can see our team with this [link](https://www.opensquare.network/team/). * **Contact Name:** Yongfeng Li * **Contact Email:** wliyongfeng@gmail.com -* **Website:** https://www.opensquare.network +* **Website:** ### Legal Structure + * **Registered Address:** 3 FRASER STREET #05-25, DUO TOWER, SINGAPORE 189352 * **Registered Legal Entity:** OPENSQUARE FOUNDATION LTD. ### Team's experience We have more than 3 years experience with Substrate/Polkadot related tech stack. Our recently developing products include: -- [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve the treasury mechanism with retrospection. -- [Statescan](https://www.statescan.io), a fungible asset explorer for Statemint implementation chains. -- OpenSquare bounties business built on substrate. We got a grant for this, and please check details [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/open_square_network.md). +* [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve the treasury mechanism with retrospection. +* [Statescan](https://www.statescan.io), a fungible asset explorer for Statemint implementation chains. +* OpenSquare bounties business built on substrate. We got a grant for this, and please check details [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/open_square_network.md). We are honored that either dotreasury or statescan get support from kusama or polkadot treasury, and our work about bounties is granted by w3f previously. We are confident to deliver a high quality and usable off-chain voting site. ### Team Code Repos -https://github.com/opensquare-network/ + Team members github accounts: -- https://github.com/wliyongfeng -- https://github.com/hyifeng -- https://github.com/qiyisi -- https://github.com/YoshiyukiSakura -- https://github.com/Popoulosss +* +* +* +* +* ## Development Roadmap :nut_and_bolt: @@ -89,9 +92,9 @@ Only 1 milestone in this proposal, while the main goal is to check the feasibili We will put more features like more plugins and strategies in future proposals, but after this proposal we will launch it and make it available to the community. Milestone 1 — Implement Basic off-chain voting/polls logic for Polkadot & Kusama -- Estimated duration: 2 weeks -- FTE: 3 -- Costs: 8,000 USD +* Estimated duration: 2 weeks +* FTE: 3 +* Costs: 8,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -107,6 +110,6 @@ Milestone 1 — Implement Basic off-chain voting/polls logic for Polkadot & Kusa ## Future Plans -- Add more spaces, and in the future users may create their own space and customize it. -- Support plugins and more strategies so users can customize the process and voting result. -- Support voting by assets issued on statemine or erc-20 tokens. +* Add more spaces, and in the future users may create their own space and customize it. +* Support plugins and more strategies so users can customize the process and voting result. +* Support voting by assets issued on statemine or erc-20 tokens. diff --git a/applications/OpenSquare_paid_qa_protocol.md b/applications/OpenSquare_paid_qa_protocol.md index bc1e02193c2..ebfed8a3314 100644 --- a/applications/OpenSquare_paid_qa_protocol.md +++ b/applications/OpenSquare_paid_qa_protocol.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# OpenSquare Paid QA protocol -* **Project Name:** OpenSquare Paid QA protocol * **Team Name:** OpenSquare * **Payment Address:** 0x4905083abdD13bd95345A871701Fd0b08AbD46d1 (USDT) @@ -41,42 +40,42 @@ DAPP implementers may do the submission in a batch way. The packages or components we have to implement includes: -- A scan package which tracks the interactions on a blockchain, and stores the structured data to the database. -- Scripts which interact with IPFS, fetch or upload content. -- A restful server will handle api calls from user interfaces and serve the structured data to them. -- A backend job which aggregates the signed answers and submits them to blockchain in a batch extrinsic. -- User interfaces. +* A scan package which tracks the interactions on a blockchain, and stores the structured data to the database. +* Scripts which interact with IPFS, fetch or upload content. +* A restful server will handle api calls from user interfaces and serve the structured data to them. +* A backend job which aggregates the signed answers and submits them to blockchain in a batch extrinsic. +* User interfaces. The user interfaces will include: -- A topic list page where users can see all the topics. Each topic is shown with its author, title, created time, +* A topic list page where users can see all the topics. Each topic is shown with its author, title, created time, status, etc. There may be some filters, like token currency filter and amount filter. -- A topic authoring page where a topic author can edit the topic, sign the extrinsic and submit to blockchain. -- A topic detail page: - - It shows the topic details and the answers. - - A user can answer the topic and sign with his/her polkadot key. - - A user can support this topic and sign the extrinsic to blockchain. - - Any user can fund an answer or the topic. - - It will show all the fund records, including from, to and the funded tokens. - - The author and supporter can resolve the topic on this page. -- A user page which is identified by address: - - A list of the created/supported topics. - - A list answers. - - Statistics of funds granted and received. - - Maybe some interfaces for operations, like links to create a topic. -- In site notifications(centralized) - - A topic author/supporter will receive a notification when there are new answers. - - An answer author will receive a notification when his/her answer gets funded. +* A topic authoring page where a topic author can edit the topic, sign the extrinsic and submit to blockchain. +* A topic detail page: + * It shows the topic details and the answers. + * A user can answer the topic and sign with his/her polkadot key. + * A user can support this topic and sign the extrinsic to blockchain. + * Any user can fund an answer or the topic. + * It will show all the fund records, including from, to and the funded tokens. + * The author and supporter can resolve the topic on this page. +* A user page which is identified by address: + * A list of the created/supported topics. + * A list answers. + * Statistics of funds granted and received. + * Maybe some interfaces for operations, like links to create a topic. +* In site notifications(centralized) + * A topic author/supporter will receive a notification when there are new answers. + * An answer author will receive a notification when his/her answer gets funded. Please check part of the UIs [here](https://www.figma.com/proto/vqpglMGW8psHKB00eIVDUV/OpenSquare?page-id=3655%3A16149&node-id=3659%3A30988&viewport=322%2C48%2C0.08&scaling=min-zoom). ### Ecosystem Fit -- It’s `system#remark` based, lightweight, and gas free for topic answers. -- Target audience are all the community members who have questions to ask or topics to discuss, and who have knowledge +* It’s `system#remark` based, lightweight, and gas free for topic answers. +* Target audience are all the community members who have questions to ask or topics to discuss, and who have knowledge to share. -- It provides a way with bounty for Pokadot ecosystem community members to share knowledge. -- I know [mem.co](https://mem.co/) who has similar planned products, but currently seems no products released. We +* It provides a way with bounty for Pokadot ecosystem community members to share knowledge. +* I know [mem.co](https://mem.co/) who has similar planned products, but currently seems no products released. We OpenSquare developed a centralized paid QA platform in Chinese, but we think decentralization should be the right direction. @@ -84,11 +83,11 @@ Please check part of the UIs [here](https://www.figma.com/proto/vqpglMGW8psHKB00 ### Team members -- Yongfeng Li(@wliyongfeng), Full stack developer -- Chaojun Huang(@hyifeng), Full stack developer -- Wentao Chen(@qiyisi), Full stack developer -- Yizhou Xin(@YoshiyukiSakura), Full stack developer -- Alcazar(@Popoulosss), Designer +* Yongfeng Li(@wliyongfeng), Full stack developer +* Chaojun Huang(@hyifeng), Full stack developer +* Wentao Chen(@qiyisi), Full stack developer +* Yizhou Xin(@YoshiyukiSakura), Full stack developer +* Alcazar(@Popoulosss), Designer You can see our team [here](https://www.opensquare.network/team/). @@ -96,7 +95,7 @@ You can see our team [here](https://www.opensquare.network/team/). * **Contact Name:** Yongfeng Li * **Contact Email:** wliyongfeng@gmail.com -* **Website:** https://www.opensquare.network +* **Website:** ### Legal Structure @@ -108,41 +107,41 @@ You can see our team [here](https://www.opensquare.network/team/). We have more than 3 years experience with Substrate/Polkadot related tech stack. Our recently developing products include: -- [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve +* [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve the treasury mechanism with retrospection. -- [Statescan](https://www.statescan.io). An explorer for asset para chains, and we have implemented +* [Statescan](https://www.statescan.io). An explorer for asset para chains, and we have implemented Statemine/Statemint/Westmint. -- OpenSquare bounties business built on substrate. We got a grant for this, and please check +* OpenSquare bounties business built on substrate. We got a grant for this, and please check details [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/open_square_network.md). -- OpenSquare off chain [voting](https://voting.opensquare.io/) platform. We got a grant to develop it, please check +* OpenSquare off chain [voting](https://voting.opensquare.io/) platform. We got a grant to develop it, please check details [here](https://github.com/w3f/Grants-Program/blob/master/applications/OpenSquare-offchain-voting.md). We have supported Statemine assets since the grant delivery and got RMRK as our first user. ### Team Code Repos -https://github.com/opensquare-network/ + Team members github accounts: -- https://github.com/wliyongfeng -- https://github.com/hyifeng -- https://github.com/qiyisi -- https://github.com/YoshiyukiSakura -- https://github.com/Popoulosss +* +* +* +* +* ## Development Roadmap :nut_and_bolt: ### Overview -- **Total Estimated Duration:** 6 weeks -- **Full-Time Equivalent (FTE):** 5 FTE -- **Total Costs:** 25,000 USD +* **Total Estimated Duration:** 6 weeks +* **Full-Time Equivalent (FTE):** 5 FTE +* **Total Costs:** 25,000 USD Milestone 1 — Implement the paid QA businesses -- **Total Estimated Duration:** 6 weeks -- **Full-Time Equivalent (FTE):** 5 FTE -- **Total Costs:** 25,000 USD +* **Total Estimated Duration:** 6 weeks +* **Full-Time Equivalent (FTE):** 5 FTE +* **Total Costs:** 25,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -170,10 +169,10 @@ Milestone 1 — Implement the paid QA businesses ## Future Plans -- Support more chains and add more token identifiers, so users can collaborate with more tokens. -- Add more topic field definitions, so users can collaborate with more ways, for example, a field to support a poll +* Support more chains and add more token identifiers, so users can collaborate with more tokens. +* Add more topic field definitions, so users can collaborate with more ways, for example, a field to support a poll topic, a field to help users make categories. -- Credit/reputation building based on the behaviors, but it will be a long pan which need considerations together with +* Credit/reputation building based on the behaviors, but it will be a long pan which need considerations together with other collaborations in OpenSquare developed platforms. ## Additional Information :heavy_plus_sign: diff --git a/applications/ParaSpell.md b/applications/ParaSpell.md index f5a648737b4..950450b884f 100644 --- a/applications/ParaSpell.md +++ b/applications/ParaSpell.md @@ -1,9 +1,8 @@ -# W3F Grant Proposal +# ParaSpell -- **Project Name:** ParaSpell -- **Team Name:** ParaSpell -- **Payment Address:** 0xa085190c859eAe92bCCED9CE05b10DDb363FE5Ea (USDC) -- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 🐣 +- **Team Name:** ParaSpell +- **Payment Address:** 0xa085190c859eAe92bCCED9CE05b10DDb363FE5Ea (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 🐣 ## Project Overview 📄 @@ -12,15 +11,18 @@ XCM & XCMP related development tool for developers. ParaSpell main advantages can be summarized in the following list: -- ParaSpell is a platform that allows developers to use specific XCM & XCMP related tasks from a user-friendly interface. -- ParaSpell focuses on ease of use, broad scale of use cases, and bringing XCM & XCMP utilization & documentation closer to developers. -- ParaSpell guarantees to be a completely decentralized, open-source platform that does not collect any user data. + +- ParaSpell is a platform that allows developers to use specific XCM & XCMP related tasks from a user-friendly interface. +- ParaSpell focuses on ease of use, broad scale of use cases, and bringing XCM & XCMP utilization & documentation closer to developers. +- ParaSpell guarantees to be a completely decentralized, open-source platform that does not collect any user data. One of the ParaSpell main goals is to reduce the time necessary to create XCM calls or open HRMP channels. -![comparisonImg](https://user-images.githubusercontent.com/55763425/198575362-929a94fc-b118-42de-95b4-b8ac358be3bc.jpg) +[ +![Opening channel screen](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/comparisonImg.jpg) +](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/comparisonImg.jpg) -As we can see in the figure above, the amount of details the user has to fill to transfer the XCM message is drastically reduced. As an example, users do not need to specify a specific route from origin to destination chain. These details are filled for them. +As we can see in the figure above, the amount of details the user has to fill to transfer the XCM message is drastically reduced. As an example, users do not need to specify a specific route from origin to destination chain. These details are filled for them. Another goal of ParaSpell is having network installation, compilation & startup done as simply as possible. This is achieved by makefile that groups commands into fewer much more intuitive commands and by network startup configuration file. Together, these two files take care of the network side, and adding new nodes into these files is intuitive. Starting the application is also very simple and done by one command. Communication between application and network is made possible with Polkadot API libraries. @@ -33,49 +35,57 @@ Overall ParaSpell is all about developer experience. ParaSpell in its current form allows developers to install all dependencies as well as a network consisting of Rococo, Pichiu(Kylin network), Bifrost & Acala nodes with one command. Launching a network is also done by one command. Once the network is installed and started ParaSpell application allows developers to open/close HRMP channels between mentioned parachains. In current progress ParaSpell already has user interface and main functionality almost finished. The following screen allows the user to open the HRMP channels between list of parachains pulled from Rococo by API call. -Open channel - +[ +![Opening channel screen](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/Open%20channel.png) +](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/Open%20channel.png) Closing HRMP channels is just as simple as opening them. One button click to close the required channel. -close channel - +[ +![Closing channel screen](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/close%20channel.png) +](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/close%20channel.png) If the user decides to transfer funds from Relay chain to Parachain they can do so by filling following details. These required details are way faster to fill than filling a full XCM call which requires a complete route and selection of concrete token. -relay to para +[ +![Relay to para screen](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/relay%20to%20para.png) +](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/relay%20to%20para.png) The opposite, but nearly the same scenario is sending tokens from Parachain to Relay chain. It is just as simple, however. -para to relay - +[ +![Para to relay screen](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/para%20to%20relay.png) +](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/para%20to%20relay.png) The last transaction scenario is the transfer of funds between Parachain and another Parachain. -para to para - +[ +![Para to para screen](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/para%20to%20para.png) +](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/para%20to%20para.png) - Overview video of application is also available on Youtube [Link to overview video](https://youtu.be/YKZEa2MaY6Q) #### Architecture 🏗 -![screenFlow](https://user-images.githubusercontent.com/55763425/198412240-e031d877-c5d8-4952-9048-2e1256ba4469.svg) +[ +![Diagram](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/screenFlow.svg) +](https://raw.githubusercontent.com/dudo50/Polkachange/main/img/screenFlow.svg) Application is purposely designed to be as simple as possible. This guarantees, that all tasks can be done quickly and without extended searching. All necessary screens also feature notifications which will as a milestone explain be callback reactive. The loading screen is only present on the first application & network startup, once accessing the same screen after the application was loaded it will be skipped automatically. The screen serves to register necessary assets in parachain nodes. This is only required to be run once per network startup. #### Technology Stack 💻 -- Vue.js -- Node.js -- Typescript -- Polkadot api libraries -- Make +- Vue.js +- Node.js +- Typescript +- Polkadot api libraries +- Make - Polkadot launch -- Substrate compatible nodes (For now Rococo, Pichiu(Kylin network), Bifrost & Acala) +- Substrate compatible nodes (For now Rococo, Pichiu(Kylin network), Bifrost & Acala) ### Ecosystem Fit 🌿 -There are not many XCM & XCMP related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster. +There are not many XCM & XCMP related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster. -In Polkadot and Kusama ecosystem, there are few XCM & XCMP related Dapps in development. These rather focus on standard users mostly. One of mentioned type is called "Morph". +In Polkadot and Kusama ecosystem, there are few XCM & XCMP related Dapps in development. These rather focus on standard users mostly. One of mentioned type is called "Morph". Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains. @@ -91,13 +101,13 @@ Viktor Valaštín - Supervisor, founder of [KodaDot](https://kodadot.xyz/). Facu ### Contact 📞 -- **Contact Name:** Dušan Morháč -- **Contact Email:** [xmorhac@stuba.sk](mailto:xmorhac@stuba.sk) +- **Contact Name:** Dušan Morháč +- **Contact Email:** [xmorhac@stuba.sk](mailto:xmorhac@stuba.sk) ### Legal Structure -- **Registered Address:** No legal structure yet. -- **Registered Legal Entity:** No legal structure yet. +- **Registered Address:** No legal structure yet. +- **Registered Legal Entity:** No legal structure yet. ### Team's experience 🔎 @@ -106,51 +116,52 @@ Viktor Valaštín - Supervisor, founder of [KodaDot](https://kodadot.xyz/). Facu ### Team Code Repos 📚 -- [https://github.com/dudo50/ParaSpell](https://github.com/dudo50/ParaSpell) -- [https://github.com/kodadot/nft-gallery](https://github.com/kodadot/nft-gallery) +- [https://github.com/dudo50/ParaSpell](https://github.com/dudo50/ParaSpell) +- [https://github.com/kodadot/nft-gallery](https://github.com/kodadot/nft-gallery) #### Team github accounts 🧑‍💻 -- [https://github.com/dudo50](https://github.com/dudo50) Dušan Morháč -- [https://github.com/vikiival](https://github.com/vikiival) Viktor Valaštín + +- [https://github.com/dudo50](https://github.com/dudo50) Dušan Morháč +- [https://github.com/vikiival](https://github.com/vikiival) Viktor Valaštín ### Team LinkedIn Profiles 🧑‍🎓 -- [https://www.linkedin.com/in/dudo50](https://www.linkedin.com/in/dudo50) -- [https://www.linkedin.com/in/vikival](https://www.linkedin.com/in/vikival) +- [https://www.linkedin.com/in/dudo50](https://www.linkedin.com/in/dudo50) +- [https://www.linkedin.com/in/vikival](https://www.linkedin.com/in/vikival) ## Development Status 📖 -- [https://github.com/dudo50/ParaSpell](https://github.com/dudo50/ParaSpell) This is the repo for ParaSpell and there is already a user interface that can open HRMP channels & transfer fungible tokens between Acala and Rococo. Wallet support from milestone was recently implemented, it only needs to be added to calls. +- [https://github.com/dudo50/ParaSpell](https://github.com/dudo50/ParaSpell) This is the repo for ParaSpell and there is already a user interface that can open HRMP channels & transfer fungible tokens between Acala and Rococo. Wallet support from milestone was recently implemented, it only needs to be added to calls. ## Development Roadmap 🔩🛠 ### Overview -- **Total Estimated Duration:** 2 months ⌛️ -- **Full-Time Equivalent (FTE):** 1 FTE -- **Total Costs:** 10,000 USD 💰 +- **Total Estimated Duration:** 2 months ⌛️ +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 10,000 USD 💰 ### Milestone 1 — Cross-blockchain application for developers -- **Estimated duration:** 2 months ⌛️ -- **FTE:** 1 FTE -- **Costs:** 10,000 USD 💰 +- **Estimated duration:** 2 months ⌛️ +- **FTE:** 1 FTE +- **Costs:** 10,000 USD 💰 | Number | Deliverable | Specification | |--------|---------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 0a. | License | MIT | -| 0b. | Documentation | Inline documentation of code, as well as startup
          configuration with all necessary commands, included
          in repository | -| 0c. | Testing Guide | Core functionality & user guide will be covered in
          repository documentation | +| 0b. | Documentation | Inline documentation of code, as well as startup configuration with all necessary commands, included in repository | +| 0c. | Testing Guide | Core functionality & user guide will be covered in repository documentation | | 0d. | Docker | Frontend Docker file will be ready | | 0e. | Article | Soon to be released on IEEE + Medium article about development of ParaSpell | -| 1. | Wallet login | Developers can use their Polkadot js
          extension wallets to execute transactions XCM
          from their accounts. | -| 2.a | Full working
          fund transfer
          scenario 1 | Fully working transaction
          scenario 1 - Relay chain to Parachains | -| 2.b | Fully working
          fund transfer
          scenario 2 | Fully working transaction
          scenario 2 - Parachains to Relay chain | -| 2.c | Fully working
          fund transfer
          scenario 3 | Fully working transaction
          scenario 3 - Parachain to Parachain | | -| 3.a | Callback support 1 | Added callback data support so developers/users
          can see information about their XCM transactions
          from UI and in real-time. | -| 3.b | Callback support 2 | Added callback data support so developers/users
          can see information about HRMP channel calls
          from UI and in real-time. | +| 1. | Wallet login | Developers can use their Polkadot js extension wallets to execute transactions XCM from their accounts. | +| 2.a | Full working fund transfer scenario 1 | Fully working transaction scenario 1 - Relay chain to Parachains | +| 2.b | Fully working fund transfer scenario 2 | Fully working transaction scenario 2 - Parachains to Relay chain | +| 2.c | Fully working fund transfer scenario 3 | Fully working transaction scenario 3 - Parachain to Parachain | | +| 3.a | Callback support 1 | Added callback data support so developers/users can see information about their XCM transactions from UI and in real-time. | +| 3.b | Callback support 2 | Added callback data support so developers/users can see information about HRMP channel calls from UI and in real-time. | | 4. | ParaSpell SDK | Move calls to separate NPM library | -| 5. | Guide to add new
          nodes to application
          and network | Simplified and user-friendly wiki/guide for
          users to understand how to add new nodes to
          network startup configuration as well as to
          add/understand calls used in application | +| 5. | Guide to add new nodes to application and network | Simplified and user-friendly wiki/guide for users to understand how to add new nodes to network startup configuration as well as to add/understand calls used in application | ## Future Plans 🔭 @@ -164,8 +175,9 @@ In a long run, we also want to improve design, add new features that can be usef **How did you hear about the Grants Program?** Personal recommendation **About project success so far:** + - Project article was accepted on international conference ICECET2022 ( only 450 out of 1000+ articles got accepted) -[Link to conference physical program - Article 862 ](http://www.icecet.com/program_P.pdf) +[Link to conference physical program - Article 862](http://www.icecet.com/program_P.pdf) - Project won 🥈 second place bounty at Polkadot North America Hackaton in category "Build an XCM Related Tool for Moonbeam" diff --git a/applications/Parallel.md b/applications/Parallel.md index 2fbb92abe21..a26dd3aa2e2 100644 --- a/applications/Parallel.md +++ b/applications/Parallel.md @@ -1,8 +1,8 @@ -# Parallel Finance Open Grant Proposal +# Parallel Finance -- **Project Name:** Parallel Finance -- **Team Name:** Parallel -- **Payment Address:** 0x17816E9A858b161c3E37016D139cf618056CaCD4 +- **Project Name:** Parallel Finance +- **Team Name:** Parallel +- **Payment Address:** 0x17816E9A858b161c3E37016D139cf618056CaCD4 ## Project Overview :page_facing_up: @@ -12,27 +12,27 @@ Parallel finance is a decentralized lending/borrowing and staking protocol built Our platform offers a few key features and benefits: -- **Lending and borrowing**: users can lend and borrow assets based on interest rates. -- **Staking**: users can participate in Polkadot’s network validation and earn rewards. -- **Earning double interests**: users can choose to stake and lend out their tokens simultaneously based on our new approach. -- **Powered by Substrate**: our platform benefits from the speed, resiliency and convenient upgradability of Polkadot. +- **Lending and borrowing**: users can lend and borrow assets based on interest rates. +- **Staking**: users can participate in Polkadot’s network validation and earn rewards. +- **Earning double interests**: users can choose to stake and lend out their tokens simultaneously based on our new approach. +- **Powered by Substrate**: our platform benefits from the speed, resiliency and convenient upgradability of Polkadot. Our project utilizes substrate framework and is built on top of polkadot parachain ecosystem: -- We built the core interests model and functionalities on substrate runtime -- We enabled off-chain worker to query the current price feed of DOT and other tokens -- We will build cross-chain interoperability using XCMP protocol in the near future +- We built the core interests model and functionalities on substrate runtime +- We enabled off-chain worker to query the current price feed of DOT and other tokens +- We will build cross-chain interoperability using XCMP protocol in the near future **Why are we building Parallel Finance?** -- We decided to pick this idea because of the rising demand for decentralized lending protocols on Polkadot and Kusama, as well as the lack of token liquidity that comes with staking on the mainnet. We estimate that 50% of all existing DOT and KSM tokens will be staked for blockchain validation with an estimated staking APY of 10-20%. However, the DOT and KSM tokens will lose their liquidity once they are staked to validate the network. Institutions and large token holders have high incentives to use our platform since it will allow them to not only participate in staking, but also generate additional profits through lending, and allow them to use their DOTs and KSMs as payment, or trading assets. +- We decided to pick this idea because of the rising demand for decentralized lending protocols on Polkadot and Kusama, as well as the lack of token liquidity that comes with staking on the mainnet. We estimate that 50% of all existing DOT and KSM tokens will be staked for blockchain validation with an estimated staking APY of 10-20%. However, the DOT and KSM tokens will lose their liquidity once they are staked to validate the network. Institutions and large token holders have high incentives to use our platform since it will allow them to not only participate in staking, but also generate additional profits through lending, and allow them to use their DOTs and KSMs as payment, or trading assets. ### Project Details ##### MVP links -- Testnet demo: https://parallel.fi/#/ -- Video demo: https://youtu.be/lgQX9rELpL8 +- Testnet demo: +- Video demo: #### Mockups and UI components @@ -69,78 +69,79 @@ The lending protocol was inspired by compound protocol and our blockchain soluti ##### What your project is _not_ or will _not_ provide or implement -- Our team does not plan on implementing the support for other tokens besides the native DOT and KSM tokens and Stable Coin at the initial launch in order to reduce the risks in cross-collaterals -- We will not implement a decentralized exchange by ourselves. Instead, we will be focusing on building the lending/borrowing and staking protocol. +- Our team does not plan on implementing the support for other tokens besides the native DOT and KSM tokens and Stable Coin at the initial launch in order to reduce the risks in cross-collaterals +- We will not implement a decentralized exchange by ourselves. Instead, we will be focusing on building the lending/borrowing and staking protocol. ### Ecosystem Fit -- **Where and how does your project fit into the ecosystem?** We are aiming to offer the first decentralized lending/borrowing and staking protocol in the Polkadot and Kusama ecosystem as a DeFi and a parachain. -- **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** Our target audience are the DOT and KSM token holders who are looking to participate in lending/borrowing, staking and unlocking liquidity for their staked tokens, or generating "double interests" returns by lending and staking simultaneously. This audience would include retail, institutional and large token holders, traders (arbitrage opportunities in DeFi) and network validators. In general, large token holders will have a higher incentive to join the platform earlier as the exchange rate will be more favorable. -- **What need(s) does your project meet?** Our project helps generate additional interests for token holders, provide assets for borrowing and unlock liquidity for token stakers who can use staked tokens (ex: xDOT) to trade, lend or use as payment. -- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** - - **If so, how is your project different?** Compound has been a successful and proven model for lending and borrowing assets in a decentralized manner in the Ethereum ecosystem. However, Compound doesn't offer staking services, and there is currently no decentralized lending/borrowing solution launched in the Polkadot ecosystem. Acala Network does offer staking services, but doesn't offer lending/borrowing services. From that perspective, we are a unique solution that combines both services and offers additional interests to our users. - - **If not, are there similar projects in related ecosystems?** We have not yet found a project that will be focusing on generating double interests for token holders through lending and staking. +- **Where and how does your project fit into the ecosystem?** We are aiming to offer the first decentralized lending/borrowing and staking protocol in the Polkadot and Kusama ecosystem as a DeFi and a parachain. +- **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** Our target audience are the DOT and KSM token holders who are looking to participate in lending/borrowing, staking and unlocking liquidity for their staked tokens, or generating "double interests" returns by lending and staking simultaneously. This audience would include retail, institutional and large token holders, traders (arbitrage opportunities in DeFi) and network validators. In general, large token holders will have a higher incentive to join the platform earlier as the exchange rate will be more favorable. +- **What need(s) does your project meet?** Our project helps generate additional interests for token holders, provide assets for borrowing and unlock liquidity for token stakers who can use staked tokens (ex: xDOT) to trade, lend or use as payment. +- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** + - **If so, how is your project different?** Compound has been a successful and proven model for lending and borrowing assets in a decentralized manner in the Ethereum ecosystem. However, Compound doesn't offer staking services, and there is currently no decentralized lending/borrowing solution launched in the Polkadot ecosystem. Acala Network does offer staking services, but doesn't offer lending/borrowing services. From that perspective, we are a unique solution that combines both services and offers additional interests to our users. + - **If not, are there similar projects in related ecosystems?** We have not yet found a project that will be focusing on generating double interests for token holders through lending and staking. ## Team :busts_in_silhouette: ### Team members -- Name of team leader: Yubo Ruan -- Names of team members: Remi Gai, Zhou Yang, Li Pai, Cheng Jiang, Hai Yi +- Name of team leader: Yubo Ruan +- Names of team members: Remi Gai, Zhou Yang, Li Pai, Cheng Jiang, Hai Yi ### Contact -- **Contact Name:** Yubo Ruan -- **Contact Email:** yubo@parallel.fi -- **Website:** www.parallel.fi +- **Contact Name:** Yubo Ruan +- **Contact Email:** yubo@parallel.fi +- **Website:** www.parallel.fi ### Legal Structure (we are in the process of registering the legal entity) -- **Registered Address:** N/A -- **Registered Legal Entity:** N/A +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A ### Team's experience -- **Yubo Ruan**: Yubo is currently a venture investor at Polychain Capital and 8 Decimal Capital. Yubo previously worked at TrustToken as a solidity engineer and helped build the TrueFi uncollateralized lending protocol. Additionally, Yubo started Alisimba Technology with wide range of media coverage in China and was granted many national patents and innovation awards. Yubo studied computer science at Stanford University. -- **Yang Zhou**: Yang is a senior blockchain engineer at Elastos and its Gelaxy group. At Elastos, Yang contributed to the cli tool, cross-chain protocol, and merged mining specification. Additionally, Yang was the point of contact with the world's top mining pool (F2Pool, BTCPool, ANTPool, and Huobipool), and successfully launched the Elastos mining business. Yang also worked at large software tech companies and has 9 years of development experience. -- **Remi Gai**: Remi is a software engineer with a background in product management, entrepreneurship and venture capital, and currently works at Microsoft. Previously, Remi worked as an early stage investor at 8 Decimal Capital, a crypto/blockchain focused fund, and was the co-founder of Bitsystems, a blockchain development firm based in Cambridge, Massachusetts. -- **Lipai Zhu**: Lipai has 4 years of experience in blockchain. For the past 2 years, Li Pai has been working as a blockchain engineer at JianXinZhuHe technology at Shenzhen and focuses on consortium blockchain. Prior, Lipai studied BitCoin, Ethereum and Solidity and won a prize at BSN Second developer competition and a grand prize at the 4th China Blockchain Development Competition (In Competition, his duty is design smart contract and develop it). -- **Cheng Jiang**: Cheng Jiang is a senior Fullstack Developer at Ubudu, experienced in Fullstack development, Network topology and Indoor Location System Algorithms. -- **Hai Yi**: Hai Yi has 4 years experience in software engineering. He was a former software engineer at Swissborg, and trading product associate at the Bank of Montreal. Hai Yi holds a BSc in Computer Science degree from the University of Waterloo). +- **Yubo Ruan**: Yubo is currently a venture investor at Polychain Capital and 8 Decimal Capital. Yubo previously worked at TrustToken as a solidity engineer and helped build the TrueFi uncollateralized lending protocol. Additionally, Yubo started Alisimba Technology with wide range of media coverage in China and was granted many national patents and innovation awards. Yubo studied computer science at Stanford University. +- **Yang Zhou**: Yang is a senior blockchain engineer at Elastos and its Gelaxy group. At Elastos, Yang contributed to the cli tool, cross-chain protocol, and merged mining specification. Additionally, Yang was the point of contact with the world's top mining pool (F2Pool, BTCPool, ANTPool, and Huobipool), and successfully launched the Elastos mining business. Yang also worked at large software tech companies and has 9 years of development experience. +- **Remi Gai**: Remi is a software engineer with a background in product management, entrepreneurship and venture capital, and currently works at Microsoft. Previously, Remi worked as an early stage investor at 8 Decimal Capital, a crypto/blockchain focused fund, and was the co-founder of Bitsystems, a blockchain development firm based in Cambridge, Massachusetts. +- **Lipai Zhu**: Lipai has 4 years of experience in blockchain. For the past 2 years, Li Pai has been working as a blockchain engineer at JianXinZhuHe technology at Shenzhen and focuses on consortium blockchain. Prior, Lipai studied BitCoin, Ethereum and Solidity and won a prize at BSN Second developer competition and a grand prize at the 4th China Blockchain Development Competition (In Competition, his duty is design smart contract and develop it). +- **Cheng Jiang**: Cheng Jiang is a senior Fullstack Developer at Ubudu, experienced in Fullstack development, Network topology and Indoor Location System Algorithms. +- **Hai Yi**: Hai Yi has 4 years experience in software engineering. He was a former software engineer at Swissborg, and trading product associate at the Bank of Montreal. Hai Yi holds a BSc in Computer Science degree from the University of Waterloo). ### Team Code Repos -- Backend: https://github.com/parallel-finance/parallel -- Frontend: https://github.com/parallel-finance/hackathon-2021-spring/tree/main/teams/22-Parallel/src/parallel-dapp +- Backend: +- Frontend: ### Team LinkedIn Profiles -- https://www.linkedin.com/in/yubo-ruan/ -- https://www.linkedin.com/in/remigai/ -- https://www.linkedin.com/in/cheng-jiang-2a414020a/ -- https://www.linkedin.com/in/haiyi-zhong-6274108b/?originalSubdomain=ca -- https://www.linkedin.com/in/zhulipai/ -- https://www.linkedin.com/in/yz89/ +- +- +- +- +- +- ## Development Roadmap :nut_and_bolt: ### Overview + * **Total Estimated Duration:** 4 months -* **Full-time equivalent (FTE):** 4 FTE -* **Total Costs:** 9k USD +- **Full-time equivalent (FTE):** 4 FTE +- **Total Costs:** 9k USD ### Milestone 1 — Implement Cross-chain support for DOT and KSM -- **Estimated Duration:** 8 weeks -- **FTE:** 1.8 -- **Costs:** 4000 USD +- **Estimated Duration:** 8 weeks +- **FTE:** 1.8 +- **Costs:** 4000 USD The major deliverable of for this milestone: -- Implement a multi-assets lending protocol. -- Support automatic liquidation by using an off-chain worker. +- Implement a multi-assets lending protocol. +- Support automatic liquidation by using an off-chain worker. | Number | Deliverable | Specification | | -----: | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -155,22 +156,22 @@ The major deliverable of for this milestone: | 5. | User Testing | We will conduct user testing to improve our product's UI and UX, to ensure that the borrowing and lending functionalities are intuitive. Initially, we will conduct qualitative user testing by observing 10-15 users who will use the v1 platform and provide a summary of the findings and improvements made based on insights. | Other: -* We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). +- We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). ### Milestone 2 — Enable Staking for DOT and KSM -- **Estimated Duration:** 8 weeks -- **FTE:** 2.2 -- **Costs:** 5000 USD +- **Estimated Duration:** 8 weeks +- **FTE:** 2.2 +- **Costs:** 5000 USD The major deliverable of for this milestone: -- Implement the modules that allow for staking functionality, which includes - - Exchange Rate - - 28 days locking period for unstaking tokens - - Slashing scenarios - - Relay tokens to validators -- Users will be able to stake DOT tokens, and receives xDOT in return. xDOT will then start accruing interests from staking and also be used for lending or transfered elsewhere for payment or trading. Similarly, staked KSM will be converted to xKSM with the same features as xDOT. +- Implement the modules that allow for staking functionality, which includes + - Exchange Rate + - 28 days locking period for unstaking tokens + - Slashing scenarios + - Relay tokens to validators +- Users will be able to stake DOT tokens, and receives xDOT in return. xDOT will then start accruing interests from staking and also be used for lending or transfered elsewhere for payment or trading. Similarly, staked KSM will be converted to xKSM with the same features as xDOT. | Number | Deliverable | Specification | | -----: | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -187,32 +188,32 @@ The major deliverable of for this milestone: | 6. | User Testing | We will conduct user testing to improve our product's UX and UI, to ensure that the borrowing and lending functionalities are intuitive. Initially, we will conduct qualitative user testing by observing 10-15 users use the v1 platform and provide a summary of the findings and improvements made based on insights. | Other: -* We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). +- We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). ## Future Plans **Community Development**: -- In the short term, we will focus on acquiring the early users for our platform, who are large token holders and institutions. The exchange rate will be lower initially as the pool size and number of blocks are lower, so there's a strong incentive for larger players to deposit their tokens early on. As the Kusama and Polkadot mainnets are approaching, we will be forming partnership with validators who might be interested in forming partnerships or use our platform to gain liquidity on their staked tokens. -- We will frequently post on social media (Twitter, Medium, Youtube) to provide development news and video tutorials regarding our platform. We will also work with influencers, who can break down complex concepts and provide clear guidance to the mainstream users on how to use our platform. -- Our long term plan is to provide a suite of products that will allow users to earn superior interests with their assets on our Defi platform, as we truly believe in the benefits of decentralization and allowing more mainstream investors to participate in the financial economy. +- In the short term, we will focus on acquiring the early users for our platform, who are large token holders and institutions. The exchange rate will be lower initially as the pool size and number of blocks are lower, so there's a strong incentive for larger players to deposit their tokens early on. As the Kusama and Polkadot mainnets are approaching, we will be forming partnership with validators who might be interested in forming partnerships or use our platform to gain liquidity on their staked tokens. +- We will frequently post on social media (Twitter, Medium, Youtube) to provide development news and video tutorials regarding our platform. We will also work with influencers, who can break down complex concepts and provide clear guidance to the mainstream users on how to use our platform. +- Our long term plan is to provide a suite of products that will allow users to earn superior interests with their assets on our Defi platform, as we truly believe in the benefits of decentralization and allowing more mainstream investors to participate in the financial economy. **Product Development**: -- This is our tentative development roadmap for the rest of this year: +- This is our tentative development roadmap for the rest of this year: ![image](https://user-images.githubusercontent.com/56744348/111891918-94ebaa80-89c4-11eb-8707-a16b33e7b54c.png) ## Additional Information :heavy_plus_sign: -- We are a team that met and formed during the March 2021 Polkadot Hackathon in Shanghai. Our team members are both in the US and China, and come from a strong engineering background (crypto/blockchain, startup, traditional tech company), product management and financial background (venture capital, Defi). We were able to deliver our proof of concept within a month, and earned third place at the Hackathon. +- We are a team that met and formed during the March 2021 Polkadot Hackathon in Shanghai. Our team members are both in the US and China, and come from a strong engineering background (crypto/blockchain, startup, traditional tech company), product management and financial background (venture capital, Defi). We were able to deliver our proof of concept within a month, and earned third place at the Hackathon. -- We are currently still in the process of creating our white paper, but you can find more details about our documentation on our gitbook: https://docs.parallel.fi/. +- We are currently still in the process of creating our white paper, but you can find more details about our documentation on our gitbook: . -- Email: team@parallel.fi -- Website: parallel.fi -- Twitter: https://twitter.com/ParallelFi -- Medium: https://medium.com/@parallelfinance -- LinkedIn: https://www.linkedin.com/company/parallel-finance/ -- Unofficial white paper: https://docs.parallel.fi/ -- Testnet demo: https://parallel.fi/#/app -- Video demo (Hackathon March 2021): https://youtu.be/lgQX9rELpL8 +- Email: team@parallel.fi +- Website: parallel.fi +- Twitter: +- Medium: +- LinkedIn: +- Unofficial white paper: +- Testnet demo: +- Video demo (Hackathon March 2021): diff --git a/applications/Plus-follow-up.md b/applications/Plus-follow-up.md index 91322fed5e5..1821c3f6d8e 100644 --- a/applications/Plus-follow-up.md +++ b/applications/Plus-follow-up.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkadot js plus / Nomination pools -- **Project Name:** Polkadot js plus / Nomination pools - **Team Name:** Polkadot js plus - **Payment Address:** 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Plus-social-recovery-wallet.md b/applications/Plus-social-recovery-wallet.md index 8cf666bb3c6..3d75b923800 100644 --- a/applications/Plus-social-recovery-wallet.md +++ b/applications/Plus-social-recovery-wallet.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkadot js plus / Social Recovery Wallet -- **Project Name:** Polkadot js plus / Social Recovery Wallet - **Team Name:** Polkadot js plus - **Payment Address:** 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 diff --git a/applications/Plus.md b/applications/Plus.md index be37264e555..22d9c0fc462 100644 --- a/applications/Plus.md +++ b/applications/Plus.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Plus: Polkadot js plus extension -- **Project Name:** Plus: Polkadot js plus extension - **Team Name:** Kami Ekbatanifard - **Payment Address:** 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 diff --git a/applications/PolkaKey.md b/applications/PolkaKey.md index 9e60398f826..384c0133a77 100644 --- a/applications/PolkaKey.md +++ b/applications/PolkaKey.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# PolkaKey -* **Project:** PolkaKey * **Proposer:** @HiZhaoYun * **Payment Address:** 1NUYKUgjDrzXox7ebeT6xkFN5A64S419Xm diff --git a/applications/PolkaSignIn.md b/applications/PolkaSignIn.md index 4a95782e5e4..52059a7f72d 100644 --- a/applications/PolkaSignIn.md +++ b/applications/PolkaSignIn.md @@ -1,13 +1,12 @@ -# W3F Grant Proposal +# Polka SignIn -* **Project Name:** Polka SignIn -* **Team Name:** Litentry -* **Payment Address:** 0x37a45AdBb275d5d3F8100f4cF16977cd4B0f9Fb7 (USDT) +* **Team Name:** Litentry +* **Payment Address:** 0x37a45AdBb275d5d3F8100f4cF16977cd4B0f9Fb7 (USDT) * **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 > ⚠️ *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.* -## Project Overview +## Project Overview ### Overview @@ -32,9 +31,9 @@ to ask the user to sign such a magic string with injected signers and provides i #### Sign in Participants -- **Service providers** are the dApps that have the sign-in requirement. -- **Identity providers** are the injected signers which provide the authentication information of the user who holds the wallet. -- **Resource Owners** are the users who hold the self-custody crypto wallets. +* **Service providers** are the dApps that have the sign-in requirement. +* **Identity providers** are the injected signers which provide the authentication information of the user who holds the wallet. +* **Resource Owners** are the users who hold the self-custody crypto wallets. #### Workflow @@ -51,7 +50,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st ### Implementation -1. Sign-in Request +1. Sign-in Request User want to sign in the dApp by send a simple request with identity chain type, eg: DOT, KSM, ETH etc. @@ -65,7 +64,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -2. Authentication Requirement +2. Authentication Requirement dApp will return the callback info. The callback endpoint is used by Identity provider to send signature data to dApp. @@ -79,7 +78,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -3. Connect to Signer +3. Connect to Signer User sends request to the Identity Provider (Injected Signer like : Polkadot.js Extension, Metamask, Parity Signer ...). @@ -94,7 +93,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -4. Provide Signature +4. Provide Signature The Identity Provider will generate the Signature data. ``` @@ -108,15 +107,15 @@ The workflow works the same with or without OAuth specification. Only the 4th st explains: - - identity-type + * identity-type This field is used to choose the chain type and account. - - public-key + * public-key With the chain account chosen, get the public key of the account. This field will be used by dApp to decrypt the data and verify data consistency. - - account-signed + * account-signed use private key to sign the account. @@ -135,18 +134,17 @@ The workflow works the same with or without OAuth specification. Only the 4th st ``` - - scope - + * scope + scope define the permission needed for the dapp to interact with the account. - - - chanllenge - + + * chanllenge + a text string need to be signed by the private key. - The Identity Provider will send the signature data to the callback endpoint of dApp by step #3. -5. Validation +5. Validation The dApp receives the signature data and do the verification. @@ -160,18 +158,18 @@ The workflow works the same with or without OAuth specification. Only the 4th st ``` Verification Steps: - - use **public-key** to decrypt the data of **account-signed** , this progress should be successful, and get the account address. + * use **public-key** to decrypt the data of **account-signed** , this progress should be successful, and get the account address. **public-key** pairs with **private-key**, this step proves the validity of the private key, and ensure that the data was not tampered with. - - - use **public-key** to generate the address by the specified algorithmic mechanism according to the chain type, and get the account address refer to **public-key** . + * use **public-key** to generate the address by the specified algorithmic mechanism according to the chain type, and get the account address refer to **public-key** . - - verify the two account address , success if they are the same. + * verify the two account address , success if they are the same. - - if failure, it means the public key does not match the account address, it may happen when some malicious users want to impersonate an account. + * if failure, it means the public key does not match the account address, it may happen when some malicious users want to impersonate an account. + + * if success, the dApp should return the response to the Identity Provider with the payload: - - if success, the dApp should return the response to the Identity Provider with the payload: ``` { "verified": true, @@ -179,7 +177,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -6. Lookup Identity +6. Lookup Identity The dApp gets the account address . It can retrieve the related information of account from the external service providers , such as ENS, Polkadot/Kusama Identity Registrar, etc. @@ -193,7 +191,7 @@ There is few solution combine the OAuth and self-custody wallet, and no such sol * Hanwen Cheng * Yunjian Bian -* Eric Zhang +* Eric Zhang ### Contact @@ -212,15 +210,15 @@ There is few solution combine the OAuth and self-custody wallet, and no such sol ### Team Code Repos -* https://github.com/litentry -* https://github.com/litentry/litentry-parachain -* https://github.com/litentry/litentry-app +* +* +* Github accounts: -* https://github.com/hanwencheng -* https://github.com/bianyunjian -* https://github.com/jingleizhang +* +* +* ## Development Status :open_book: @@ -245,9 +243,8 @@ The hourly pay rate is 50 USD/hour In total is 120 hours, and the total payment will be 6000 USD equivalent USDT. - ## Future Plans -We planned to have a web app for user to manage the access control of the logged platforms, and enable user to curate the profile information in the future. +We planned to have a web app for user to manage the access control of the logged platforms, and enable user to curate the profile information in the future. It would be great to integrate with popular auth solutions in web technology, like passport (node js), next-auth (next.js). diff --git a/applications/Polkadart.md b/applications/Polkadart.md index 5d7838e0edf..c6e59f79ca6 100644 --- a/applications/Polkadart.md +++ b/applications/Polkadart.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkadart -- **Project Name:** Polkadart - **Team Name:** JURIMETRIC TECNOLOGIA LTDA - **Payment Address:** 12kizkmmQzRFR5o6BQ5Kufo77RPT787eaFynswQoi42vv2Da (DOT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 diff --git a/applications/Polkadot-Dart.md b/applications/Polkadot-Dart.md index add788510b8..84427d2f122 100644 --- a/applications/Polkadot-Dart.md +++ b/applications/Polkadot-Dart.md @@ -1,20 +1,16 @@ -Open Grant Proposal of Polkadot-Dart - -* **Project:** Polkadot-Dart +# Polkadot-Dart * **Proposer:** Michael So * **Payment Address:** 3PbhNyWhiSTwb58fc5uYhg2mV2vJ34KwAJ -* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/125#issuecomment-946479942) - - +* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/125#issuecomment-946479942) -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview -Dart has advantages in native development. +Dart has advantages in native development. Dart is a computer programming language developed by Google, which is used in the development of web, server, mobile apps and the IoT. Dart is an object-oriented, class-defined, single-inheritance language. Dart is a general programming language developed by Google, which was later recognized as a standard by ECMA (ECMA-408). It is used to build web, server, desktop and mobile applications. Its syntax is similar to C language and can be translated into JavaScript, interfaces, mixins, abstract classes, reified generics, optional typing and sound type system . @@ -28,9 +24,9 @@ Similarly, we also found that there is currently no Polkadot SDK suitable for th Similar to [polkaj](https://github.com/emeraldpay/polkaj) (Java version), we will develop the Dart version and name it `Polkadot-Dart`. +### Project Details -### Project Details -To complete the porting, we follow the project structure of `Polkadot-JS`. +To complete the porting, we follow the project structure of `Polkadot-JS`. There are some differences between `Dart` and `Javascript`, and the project needs to be compatible. For example, The "wasm" compiled by Rust-lang is used in `Polkadot-JS` . As for dart, we use `dart:ffi` for communication. All Rust-native libraries will be compiled to `.so` for Linux/Android system, `.a` or `.framework` for iOS/MacOS, and `.dll` for Windows. @@ -62,23 +58,21 @@ Therefore, we defined Dart project like `Polkadot-JS` . | `@polkadot/type-known` | * not needed | | `@polkadot/types` | types | - #### Technology Stacks Dart/Flutter, Rust +### Ecosystem Fit -### Ecosystem Fit +Similar projects: -Similar projects: * [Web3dart](https://github.com/simolus3/web3dart) * [polkaj](https://github.com/emeraldpay/polkaj) * [Dart-scale-codec](https://github.com/nbltrust/dart-scale-codec) -* [Substrate-sign-flutter](https://github.com/hanwencheng/substrate_sign_flutter) +* [Substrate-sign-flutter](https://github.com/hanwencheng/substrate_sign_flutter) We have created `Polkadot-Dart`, which, combined with Flutter framework, can greatly reduce the barrier to participation for cross-platform developers, as well as reduce the complexity of cross-platform application development and maintenance. In addition, the cross-platform experience of Polkadot-Dart's users is also improved. - ## Team :busts_in_silhouette: ### Team members @@ -86,12 +80,12 @@ We have created `Polkadot-Dart`, which, combined with Flutter framework, can gre * Michael So * Zhongdan Wei -### Team Website +### Team Website -* https://pocket4d.io (In progress) -* https://firestack.one +* (In progress) +* -### Legal Structure +### Legal Structure SHANGHAI NIEPAN INFORMATION TECHNOLOGY CO., LTD., a startup company focusing on blockchain development in China. @@ -100,16 +94,15 @@ SHANGHAI NIEPAN INFORMATION TECHNOLOGY CO., LTD., a startup company focusing on * Michael So, founder of FireStack, Serial entrepreneur. He devoted to blockchain for many years, leading token investment, wallet, blockchain game platform and other projects, and has accumulated rich experience in blockchain theories and practice. * Zhongdan Wei, front-end architect, proficient in Flutter. As a leading member in Hellobike, he led the team to develop the Mobike Applications and makes it easy and fast to add flutter to existing mobile applications. - ### Team Code Repos -* https://github.com/Pocket4D/p4d-rust-binding (Will be renamed after proposal is accepted) +* (Will be renamed after proposal is accepted) ### Team LinkedIn Profiles None. -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: ### Overview @@ -173,10 +166,9 @@ None. | 1 | documentations | Documentations for all packages | | 2 | pub.dev | Publish to pub.dev for v1.0.0 | - ### Community Engagement -We are buiding our community on https://www.yuque.com/?language=en-us and newsletters will be regularly updated soon. +We are buiding our community on and newsletters will be regularly updated soon. ## What has been done so far? @@ -192,22 +184,25 @@ We are buiding our community on https://www.yuque.com/?language=en-us and newsle | ☐ | 5 | network | Porting and implements `@polkadot/network` | | ☑ | 6 | tests | Unit tests for deliverables above | - ## Future Plans ### Maintainance + 1. Keep following the upgrade of `Polkadot-JS` and `Substrate`, and supporting latest upgrades as soon as possible. 2. Seperate the rust/dart binding libs and other implementations to serveral packages, the native binding libs should be minimize and stable for long term, just like `@polkadot/wasm` does. And we should be focusing on upgrading the features. ### Products and ecosystems -1. We have a plan of making a wallet app, using `Polkadot-Dart` as its main dependency, which has been communicated with many parachains, to prepare for linking into `Parachains` and lowering the threshold for users to use. + +1. We have a plan of making a wallet app, using `Polkadot-Dart` as its main dependency, which has been communicated with many parachains, to prepare for linking into `Parachains` and lowering the threshold for users to use. 2. We also have another substrate-based project called [Pocket4D](https://github.com/Pocket4D/), combining `Polkadot-Dart` and other components, we plan to build a new decentralized network. And `Polkadot-Dart` will be one of our client side core dependency. 3. The main purpose of this lib is to co-operate with ecosystem partners, especially `Parachains`, we need to build and test with them and fit their needs. - ## Additional Information ➕ + ### Are there are any teams who have already contributed (financially) to the project? + No. ### Have you applied for other grants so far? + [Pocket4D](https://github.com/w3f/General-Grants-Program/pull/340) diff --git a/applications/Polkadot_Web_UI.md b/applications/Polkadot_Web_UI.md index 026735db5af..1447abbe970 100644 --- a/applications/Polkadot_Web_UI.md +++ b/applications/Polkadot_Web_UI.md @@ -1,5 +1,5 @@ -# Open Grant Proposal -* **Project Name:** Polkadot UI Web Identicon + Angular Identicon +# Polkadot UI Web Identicon + Angular Identicon + * **Team Name:** RidOne Technologies * **Payment Address:** DAI 0xfA34F566bDDcA92Dc656310F08AC5aE64fC46456 ## Project Overview diff --git a/applications/Polkaholic.md b/applications/Polkaholic.md index e7a49fc42a1..7a131866f1d 100644 --- a/applications/Polkaholic.md +++ b/applications/Polkaholic.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkaholic.io's Multi-Chain Substrate Block Explorer -- **Project Name:** Polkaholic.io's Multi-Chain Substrate Block Explorer - **Team Name:** Colorful Notion - **Payment Address:** Polkadot 13rTinCWgc38a2wZzme28dFbViQraCowTRjQqFLEWwdMTvFW - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Polkawatch.md b/applications/Polkawatch.md index 3ad78603056..981f45c055e 100644 --- a/applications/Polkawatch.md +++ b/applications/Polkawatch.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkawatch -- **Project Name:** Polkawatch - **Team Name:** Valletech AB - **Payment Address:** 0xA39bD6af74f8c317F45137d2ED7F4e13176d916B (ETH/DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Primis.md b/applications/Primis.md index 6c70cedbe23..e3b5e733bcd 100644 --- a/applications/Primis.md +++ b/applications/Primis.md @@ -1,7 +1,5 @@ -# W3F Grant Proposal +# Primis - -- **Project Name:** Primis - **Team Name:** Primis - **Payment Address:** 0x0Ad212E301AD590f4E70dA0c0Aa2912273cB4098 (USDC) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 @@ -10,26 +8,28 @@ ## Project Overview ### Overview + Primis Desktop provides a one-stop Web3 integrated client for the Polkadot ecosystem. ### Primis Web3 Desktop for Polkadot + **Primis Wallet** Primis Desktop Wallet is the best tool to manage multi-chain assets on the Polkadot ecosystem, such as Polkadot, Kusama, and other parachains. Asset management mainly includes digital/NFT assets checking, sending, receiving, and trading records on the Polkadot ecosystem. **P2P Chat** -Primis Desktop provides encrypted chat groups for Polkadot ecosystem users to discuss decentralized Gov2 governance and Proposal freely. ZK-Proof technology will be combined into Primis chat groups to offer more privacy and decentralized DAO governance space.  +Primis Desktop provides encrypted chat groups for Polkadot ecosystem users to discuss decentralized Gov2 governance and Proposal freely. ZK-Proof technology will be combined into Primis chat groups to offer more privacy and decentralized DAO governance space. Primis Desktop could automatically create encrypted chat groups for Polkadot ecosystem DApps, each DApp has its own independent chat group. - Channels For Chat -image +image - P2P Chat -image +image @@ -40,7 +40,7 @@ Primis Desktop also is a place for users to subscribe to Polkadot decentralized **Primis Web3 PNS Browser** -Primis Desktop will gestate a Chrome-compatible PNS browser for the Polkadot ecosystem, allowing Polkadot ecosystem users to access Web2 pages and interact with Web3 DApps freely. Primis Web3 PNS Browser supports Polkadot ecosystem PNS domains’ resolution and visit.  +Primis Desktop will gestate a Chrome-compatible PNS browser for the Polkadot ecosystem, allowing Polkadot ecosystem users to access Web2 pages and interact with Web3 DApps freely. Primis Web3 PNS Browser supports Polkadot ecosystem PNS domains’ resolution and visit. Unlike traditional browsers such as Chrome, Brave, and Web2 centralized Cloud Service, Primis Web3 PNS Browser is based on a data relay network, where access and application data are transmitted to clients or Primis terminals through a relay network of Primis nodes. @@ -57,7 +57,7 @@ All of our teammates truly believed in the Web3 Revolution! That's why we want t ### Tech Stack -Supported Chains: Polkadot, Kusama, and other Parachains such as Acala, Astar, and Moonbeam.  +Supported Chains: Polkadot, Kusama, and other Parachains such as Acala, Astar, and Moonbeam. Client language: Electron, React @@ -74,6 +74,7 @@ Primis is the first blockchain project known as the web3 desktop. And we want to ## Team ### Team members + Primis team has rich experience in the fields of the public chain, infrastructure, and defi. Team members' info will be released after reviewing. ### Contact @@ -84,7 +85,7 @@ Primis team has rich experience in the fields of the public chain, infrastructur ### Legal Structure -- **Registered Address:** This info will be released after reviewing +- **Registered Address:** This info will be released after reviewing - **Registered Legal Entity:** Also, this info will be released after reviewing. ### Team's experience @@ -98,13 +99,13 @@ Primis team has developed some blockchain projects, like [Metauce](metauce.org) ### Team LinkedIn Profiles (if available) -This info will be released after reviewing +This info will be released after reviewing -## Development Status +## Development Status Primis Team already completed the designing work of Primis Desktop and started working on Milestone 1 Tech Tasks. -## Development Roadmap +## Development Roadmap ### Overview @@ -134,10 +135,10 @@ Primis Team already completed the designing work of Primis Desktop and started w Short-term: After finishing all milestones, the users' amount of Primis web3 desktop will be over 50K. -Long-term: The most influenced Web3 desktop +Long-term: The most influenced Web3 desktop -## Additional Information +## Additional Information **How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/QRUCIAL_DAO.md b/applications/QRUCIAL_DAO.md index eb0a05c8f24..4e7f86b760d 100644 --- a/applications/QRUCIAL_DAO.md +++ b/applications/QRUCIAL_DAO.md @@ -1,10 +1,9 @@ -# W3F Grant Proposal +# QRUCIAL DAO > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. > > See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. -- **Project Name:** QRUCIAL DAO - **Team Name:** QRUCIAL OÜ - **Payment Address:** BTC - bc1qysscajxdstqzpe3x9x4ftr3y6l5gelggtk8a8g - **Level:** 2 @@ -33,23 +32,26 @@ We are the first connecting defensive as well as offensive security tool executi - Core components include Substrate, QRUCIAL DAO runtime, pallets and the ExoGlue. - PoC can be found in the reference QRUCIAL DAO repository below. -- What your project is _not_ or will _not_ provide or implement +- What your project is *not* or will *not* provide or implement - We won't solve business questions here, though we think our idea fill fit into the Polkadot/Kusama ecosystem. - This project won't save all the smart contracts or render manual auditors/hackers useless. Quite the opposite, by providing proven execution, we want to provide work to the manual workers who verify and validate vulnerabilities. - Main programming languages to be used: Rust, Python and JavaScript (for frontend)

          - +

          #### What is ExoSys? + ExoSys is the system that schedules audit requests and handles ExoTool connections. It is implemented as a combination of a pallet and a daemon, running on the same system as the blockchain node. ExoSys is also responsible for issuing the Non-Transferrable NFTs and keeps a track record of audit hashes and meta data. #### What is ExoTool? + Selected set of security auditor tools, packaged and adapted to be executed by the request of ExoSys. #### What is AuditorRep? + Élő's assumption is that the performance of an auditor in each audit is a random variable following a normal distributed bell curve over time. An auditor might perform significantly better or worse from one audit to the next. Using Élő their mean skill level would remain the same. @@ -59,14 +61,16 @@ If additional vulnerabilities are found or false positives are removed, the cha The increase and decrease of every individual auditor is relative to the Élő score of the original auditor and the one re-auditing a project. High ranked auditor wins: + - few points are transferred from the low ranked auditor to the higher rated one. Low rated auditor wins: -- a lot of points are transferred from the higher rated auditor to the low rated one. + +- a lot of points are transferred from the higher rated auditor to the low rated one. #### What is the CCTF talent pool? -CCTF provides a proven track record of hackers solving challenges and based on their reputation, they are awarded as manual auditors in the QDAO ecosystem. +CCTF provides a proven track record of hackers solving challenges and based on their reputation, they are awarded as manual auditors in the QDAO ecosystem. ### Ecosystem Fit @@ -113,19 +117,18 @@ Silur is working at the Hungarian Academy of Sciences (MTA) as cryptographer, wa knockoff is linux system administrator and junior rust developer. - ### Team Code Repos -- https://github.com/Qrucial/QRUCIAL-DAO -- https://github.com/Qrucial/Hacking_Substrate_with_Chaos_Pallet -- https://github.com/Qrucial/SafuDot -- https://github.com/Qrucial/QRUCIAL_Audits +- +- +- +- Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. -- https://github.com/smilingSix -- https://github.com/wigy-opensource-developer -- https://github.com/Silur +- +- +- ### Team LinkedIn Profiles (if available) @@ -139,7 +142,6 @@ We have started the development already, details can be found under this reposit The PoC is working, and we want to move forward in developing a live testnet version. - ## Development Roadmap :nut_and_bolt: ### Overview @@ -160,7 +162,7 @@ The PoC is working, and we want to move forward in developing a live testnet ver | 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 1. | Substrate runtime | The runtime config and compilable code for QRUCIAL DAO. | +| 1. | Substrate runtime | The runtime config and compilable code for QRUCIAL DAO. | | 2. | Substrate pallet: ExoSys | Core system that handles the extrinsics that request ExoTool execution. | | 3. | Substrate pallet: AuditorRep | Reputation system for the manual auditors who verify the output recorded by ExoSys. | | 4. | Substrate report storage | Includes the tools exogenous to the Substrate system, it is connected through the glue/proxy. | @@ -184,7 +186,6 @@ The PoC is working, and we want to move forward in developing a live testnet ver | 3. | ExoTool - CCA | Implement [Clippy](https://github.com/rust-lang/rust-clippy) and [Cargo Audit](https://docs.rs/cargo-audit/0.15.1/cargo_audit/) as an exotool package for ink!/WASM smart contract audits. | | 4. | ExoTool - Octopus | Implement [Octopus](https://github.com/pventuzelo/octopus) as an exotool for bytecodes (WASM and Solidity) | - ## Future Plans - In the short term, we'd like to have the grant, so development goes faster. QRUCIAL as a company will keep funding the project until it becomes self-sustaining (meaning, the governance system keeps the DAO running on its own). @@ -192,7 +193,6 @@ The PoC is working, and we want to move forward in developing a live testnet ver - Elfz'n'Trollz is a marketing partner, so we don't just develop a DAO, but also make it usable and visually acceptable to all audiences. - After final milestone, we will start building a larger community for QRUCIAL DAO and improve our partnership with CCTF. - ## Additional Information :heavy_plus_sign: **How did you hear about the Grants Program?** Personal recommendation from Achim Schneider and Jonan. diff --git a/applications/QSTN: Redefining data, De-Fi and NFTs on Substrate.md b/applications/QSTN: Redefining data, De-Fi and NFTs on Substrate.md index 6c913859d4b..323a1254213 100644 --- a/applications/QSTN: Redefining data, De-Fi and NFTs on Substrate.md +++ b/applications/QSTN: Redefining data, De-Fi and NFTs on Substrate.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# QSTN -- **Project Name:** QSTN - **Team Name:** QSTN - **Payment Address:** ETH - 0x7056A5Da7D269B31Eb2E54E5579e41ef283d7D2C - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 diff --git a/applications/RainbowDAO Protocol ink! Phase 1.md b/applications/RainbowDAO Protocol ink Phase 1.md similarity index 99% rename from applications/RainbowDAO Protocol ink! Phase 1.md rename to applications/RainbowDAO Protocol ink Phase 1.md index 839da170a90..b0561630cec 100644 --- a/applications/RainbowDAO Protocol ink! Phase 1.md +++ b/applications/RainbowDAO Protocol ink Phase 1.md @@ -1,8 +1,5 @@ -# W3F Grant Proposal +# RainbowDAO Protocol ink! Phase 1 - - -- **Project Name:** RainbowDAO Protocol ink! Phase 1 - **Team Name:** Rainbowcity Foundation - **Payment Address:** 0xC2dA4D5813978BbC43d81e905dE6C98767526EdF (DAI) - **[Level]** 2 diff --git a/applications/RareLink.md b/applications/RareLink.md index 4375f026385..87d3e050a10 100644 --- a/applications/RareLink.md +++ b/applications/RareLink.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# RareLink Protocol -* **Project:** RareLink Protocol * **Proposer:** 0x522359 * **Payment Address:** 3Ah1QWfs9oEPdhRDYkWPSJYf5yKa7NLcSF * **Status:** [Terminated](https://github.com/w3f/Open-Grants-Program/pull/86#issuecomment-874241559) diff --git a/applications/RedStone Network.md b/applications/RedStone Network.md index e8fd6372698..f6934258d2c 100644 --- a/applications/RedStone Network.md +++ b/applications/RedStone Network.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Redstone Network -- **Project Name:** Redstone Network - **Team Name:** Redstone Network - **Payment Address:** 0x24cfc36f699dacc5cb652630ddd894a8df658233 (Ethereum ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 @@ -20,11 +19,14 @@ We will work with parallel chains in Polkadot/Kusama to build and deploy the fir For the transaction firewall functionality, Redstone Network will build a set of on-chain/off-chain trigger components and their implementations. In general, users will not be aware of the firewall's operation, and the firewall will truthfully notify users of potential security risks when there are triggered alarms on the chain. #### Passive defense and active alarms -* We build a series of stateless atomic trigger components, including on-chain triggers (quantity trigger, time trigger, price trigger), off-chain triggers (mail trigger, discord trigger, slack trigger) and off-chain message interaction components, which are responsible for actively obtaining external information or pushing messages to a specified server.; -* Analyze transaction characteristics and behavior, design transaction protocol analyze the transaction characteristics and behavior, design the transaction protocol, check whether the basic information and check information of the transaction match through protocol parsing, and initially determine the validity of the transaction; -* according to the trigger and the transaction protocol, with the idea of social recovery and multiple signatures, formulate different security level trigger policies for users, including power grabbing mechanism, freezing mechanism and alarm mechanism. + +- We build a series of stateless atomic trigger components, including on-chain triggers (quantity trigger, time trigger, price trigger), off-chain triggers (mail trigger, discord trigger, slack trigger) and off-chain message interaction components, which are responsible for actively obtaining external information or pushing messages to a specified server.; + +- Analyze transaction characteristics and behavior, design transaction protocol analyze the transaction characteristics and behavior, design the transaction protocol, check whether the basic information and check information of the transaction match through protocol parsing, and initially determine the validity of the transaction; +- according to the trigger and the transaction protocol, with the idea of social recovery and multiple signatures, formulate different security level trigger policies for users, including power grabbing mechanism, freezing mechanism and alarm mechanism. #### Intelligent termination of transactions with evil address monitoring + The user-configured security scheme can effectively defend against known security problems, but not against unknown or unconfigured behaviors. By analyzing the transaction data recorded in the database under the chain, the transactions are analyzed according to the dimensions of transaction time, transaction frequency, transaction address, transaction direction, and transaction amount, and if the transaction behavior is different from the daily behavior, the meltdown mechanism will be triggered and alarmed; receiving the supervision instruction from a chain, the address that is doing evil and the derived address will be dynamically analyzed and the transaction meltdown mechanism will be triggered. For the application scenario of transaction firewall, it is mainly divided into token assets and NFT assets. Users can choose the type of asset that needs to be configured with the firewall, either for a certain token, or to protect the account that issues NFT assets. @@ -32,56 +34,66 @@ For the application scenario of transaction firewall, it is mainly divided into In addition, the transaction firewall feature is not dependent on any application, any architecture and any address type restrictions, making it flexible to handle a variety of new attack methods that are known or have not yet emerged in the future, as it aims to study the security of A to B transfers. **Technology stack** -* Rust: Develop on-chain trigger/defense/alert modules -* Go/Python: Develop off-chain analysis/trace/alarm modules + +- Rust: Develop on-chain trigger/defense/alert modules +- Go/Python: Develop off-chain analysis/trace/alarm modules ### Ecosystem Fit + This project will be developed, deployed and run based on the Substrate framework. Unlike other trigger projects, with the advanced features of OCW, we are able to provide users with an advanced on-chain alert push mechanism, which will help shorten the time for users to get critical information. At the same time, rooted in Polkadot/Kasuma ecology, as a parallel chain, the trigger interface on it will provide additional application features for all parallel chains, and with the help of relay chains, it can facilitate unique transaction defense capabilities for other parachains. We note that we are entering a completely new area that will provide an unprecedented protection experience for the blockchain space once our project is in actual operation. ## Team :busts_in_silhouette: ### Team members -- Bin Guo -- Li Smith -- yiwei Shi -- Leon +- Bin Guo +- Li Smith +- yiwei Shi +- Leon ### Contact -- **Contact Name:** Bin Guo -- **Contact Email:** bin.guo@deeper.network +- **Contact Name:** Bin Guo +- **Contact Email:** bin.guo@deeper.network ### Legal Structure + (we are in the process of registering the legal entity) -- **Registered Address:** N/A -- **Registered Legal Entity:** N/A + +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A ### Team's experience **Bin Guo** + - Over 9 years of experience in software development and project management, engaged in work related to blockchain and big data, and worked in a core research institution of State Grid (Fortune 500). - Polkadot senior ambassador, Substrate Evangelist, and early participants in the Polkadot ecosystem. - Github: https://github.com/AmadeusGB - Email: amadeusgb123@gmail.com **Smith Li** + - Over 9 years of working experience in various aspects of computer programming. - Worked in the blockchain industry for 3+ years, a blockchain development engineer, familiar with polkadot, bitshares, fabric, etc. - Hackathon winner as a team tech leader: Winners of Polkadot Hackathon 2022. - github: https://github.com/baidang201 **yiwei Shi** + - Art and management background, worked for Hearst, MSN, responsible for market and product, more than one year of blockchain development experience, familiar with computer science, cryptography and different economic mechanisms, good at Go and Rust development。Hackathon winner as a team member: Winners of Polkadot Hackathon 2022 - Github : https://github.com/shiyivei - Email : shiyivei@outlook.com **leon** + - Over 7 years of working experience in web development experience ande more than one year of blockchain development experience, familiar with FrontEnd, good at Js,Ts and Rust development.Hackathon winner as a team member: Winners of Polkadot Hackathon 2022 - github: https://github.com/walle233 ### Team Code Repos + We have forked substrate-template repository code to implement on-chain triggers (quantity triggers, time triggers, price triggers) and off-chain triggers (email triggers, slack triggers) with the help of decentralized off-chain communication components, in addition, we have implemented a simple oracle machine。 + - [difttt-node](https://github.com/difttt/difttt-node) - [evm-proxy](https://github.com/difttt/evm-proxy) - [slack-notify](https://github.com/difttt/slack-notify) @@ -89,6 +101,7 @@ We have forked substrate-template repository code to implement on-chain triggers - [frontend](https://github.com/difttt/frontend) ## Development Roadmap :nut_and_bolt: + ### Overview - **Total Estimated Duration:** 3 months @@ -108,8 +121,8 @@ We have forked substrate-template repository code to implement on-chain triggers | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 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** to explain the concept, design and implementation of the design in Grant and how to use these features in the blockchain) -| 1. | Passive_Defense Pallet | We will provide users with stateless and application-independent protective features, and this module will be implemented through Substrate Pallet:
          **transaction limit configuration**: configure in advance the limit of transferring a transaction amount and limit the frequency of transactions within a specified time; protect users from suffering significant losses for a short period of time when their private keys are stolen.
          **Freezing configuration**: advance configuration of freezing transaction time, freezing transaction type, and whether the freezing command can be withdrawn; when the user realizes that the private key has been stolen, the freezing operation will be triggered immediately to help the user further reduce losses.
          **Capture account authority configuration**: configure in advance N friend addresses and M for friend operations to take effect; when the user realizes the private key has been stolen, let the account freeze first and contact their friends as soon as possible. When more than M friends vote to pass, the authority of the stolen account will be taken over and any transaction will be executed only after N friends vote. This way even if the hacker steals the private key, he will not be able to transfer money effectively. | -| 2. | Active_Alarming Pallet | We will provide users with on-chain and off-chain alerting functions. This module will be implemented through Substrate Pallet:
          **On-chain alarm configuration**: Any transaction that exceeds the limit will send an alarm event; for example, the user can configure that when N transactions exceeding the limit amount occur within a period of time, an off-chain alarm notification will be triggered; the user can configure, a period of Within a certain time, different times will trigger different alarm methods.
          **Off-chain triggering alarms**: Provide users with three off-chain notification methods: Mail, Slack, and Discord. For example, general alarms are sent to Mail, important alarms are sent to Slack, and critical alarms are sent to Discord to achieve hierarchical management of alarms. | +| 1. | Passive_Defense Pallet | We will provide users with stateless and application-independent protective features, and this module will be implemented through Substrate Pallet:
          **transaction limit configuration**: configure in advance the limit of transferring a transaction amount and limit the frequency of transactions within a specified time; protect users from suffering significant losses for a short period of time when their private keys are stolen.
          **Freezing configuration**: advance configuration of freezing transaction time, freezing transaction type, and whether the freezing command can be withdrawn; when the user realizes that the private key has been stolen, the freezing operation will be triggered immediately to help the user further reduce losses.
          **Capture account authority configuration**: configure in advance N friend addresses and M for friend operations to take effect; when the user realizes the private key has been stolen, let the account freeze first and contact their friends as soon as possible. When more than M friends vote to pass, the authority of the stolen account will be taken over and any transaction will be executed only after N friends vote. This way even if the hacker steals the private key, he will not be able to transfer money effectively. | +| 2. | Active_Alarming Pallet | We will provide users with on-chain and off-chain alerting functions. This module will be implemented through Substrate Pallet:
          **On-chain alarm configuration**: Any transaction that exceeds the limit will send an alarm event; for example, the user can configure that when N transactions exceeding the limit amount occur within a period of time, an off-chain alarm notification will be triggered; the user can configure, a period of Within a certain time, different times will trigger different alarm methods.
          **Off-chain triggering alarms**: Provide users with three off-chain notification methods: Mail, Slack, and Discord. For example, general alarms are sent to Mail, important alarms are sent to Slack, and critical alarms are sent to Discord to achieve hierarchical management of alarms. | ### Milestone 2 Example — Intelligent meltdown mechanism, including abnormal trading meltdown, evil trading meltdown @@ -126,19 +139,20 @@ We have forked substrate-template repository code to implement on-chain triggers | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 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** explaining the concept, design and implementation of smart meltdowns and how to use these features in the blockchain) -| 1. | Analyzer Module | We will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language：
          Users can choose whether to enable the off-chain transaction analysis function. The module records and analyzes user transaction characteristics based on a counter, and uploads to the blockchain when abnormal results emerge from the analysis. When a potentially abnormal transaction occurs, the user can choose, based on advance configuration, whether the module simply alerts when an abnormal transaction is reported, or freezes the account until the user comes to deal with the problem on their own. In this case, the hacker does not trigger any on-chain restrictions, only the off-chain transaction analysis detects the anomaly | -| 2. | Tracker Module | We will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language.
          This module implements the function of tracking the transaction records of a certain address at a certain time period, helping users to assist in analyzing the loss of the current address from the hacking attack, as well as analyzing the chain through which the hacker transferred the funds. | +| 1. | Analyzer Module | We will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language：
          Users can choose whether to enable the off-chain transaction analysis function. The module records and analyzes user transaction characteristics based on a counter, and uploads to the blockchain when abnormal results emerge from the analysis. When a potentially abnormal transaction occurs, the user can choose, based on advance configuration, whether the module simply alerts when an abnormal transaction is reported, or freezes the account until the user comes to deal with the problem on their own. In this case, the hacker does not trigger any on-chain restrictions, only the off-chain transaction analysis detects the anomaly | +| 2. | Tracker Module | We will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language.
          This module implements the function of tracking the transaction records of a certain address at a certain time period, helping users to assist in analyzing the loss of the current address from the hacking attack, as well as analyzing the chain through which the hacker transferred the funds. | ## Future Plans Conceptualizing the application with the trigger concept, implementing the transaction firewall first, and refining our design based on user feedback. Implementation steps. -* develop on-chain/off-chain triggers for firewall requirements. -* refining the firewall design based on user feedback. -* implementing cross-chain transactions and providing transaction protection for cross-chain links. -* configure different levels of defense strategies based on implementation experience. + +- develop on-chain/off-chain triggers for firewall requirements. +- refining the firewall design based on user feedback. +- implementing cross-chain transactions and providing transaction protection for cross-chain links. +- configure different levels of defense strategies based on implementation experience. ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** How did you hear about the Grants Program? We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members. diff --git a/applications/Relation-Graph.md b/applications/Relation-Graph.md index 861c86e285a..083b9f997ee 100644 --- a/applications/Relation-Graph.md +++ b/applications/Relation-Graph.md @@ -1,25 +1,23 @@ -# W3F Grant Proposal +# Relation Graph > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. > > See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. -- **Project Name:** Relation Graph + - **Team Name:** Relationlabs - **Payment Address:** 0x9fE784bD844C6c7eB7a570467937e6005eEd1C4C Ethereum (USDT/DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 - **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/569#issuecomment-1299292773) - -## Project Overview :page_facing_up: +## Project Overview :page_facing_up ### Overview + `Relation Graph` is a substrate pallet that allows anyone to use GraphDB in [Substrate platform](https://substrate.io/). `Relation Graph` provides organizations with ready-to-use GraphDB service for successfully running Dapps on the Substrate. using `Relation Graph` Dapps builders can focus on bussiness logic by removing the complexities of Substrate. - ### Project Details - **Relation Graph** `Relation Graph` is a substrate pallet that allows anyone to use GraphDB in [Substrate platform](https://substrate.io/). @@ -29,9 +27,9 @@ 3、sparql as blockchain. It supports the following specifications: -* [SPARQL 1.1 Query](https://www.w3.org/TR/sparql11-query/), [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/), and [SPARQL 1.1 Federated Query](https://www.w3.org/TR/sparql11-federated-query/). -* [Turtle](https://www.w3.org/TR/turtle/), [TriG](https://www.w3.org/TR/trig/), [N-Triples](https://www.w3.org/TR/n-triples/), and [N-Quads](https://www.w3.org/TR/n-quads/). -* [SPARQL 1.1 Query Results JSON Format](https://www.w3.org/TR/sparql11-results-json/) and [SPARQL 1.1 Query Results CSV and TSV Formats](https://www.w3.org/TR/sparql11-results-csv-tsv/). +- [SPARQL 1.1 Query](https://www.w3.org/TR/sparql11-query/), [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/), and [SPARQL 1.1 Federated Query](https://www.w3.org/TR/sparql11-federated-query/). +- [Turtle](https://www.w3.org/TR/turtle/), [TriG](https://www.w3.org/TR/trig/), [N-Triples](https://www.w3.org/TR/n-triples/), and [N-Quads](https://www.w3.org/TR/n-quads/). +- [SPARQL 1.1 Query Results JSON Format](https://www.w3.org/TR/sparql11-results-json/) and [SPARQL 1.1 Query Results CSV and TSV Formats](https://www.w3.org/TR/sparql11-results-csv-tsv/). ![arch.png](https://user-images.githubusercontent.com/91399393/165587783-c55954fe-6d72-4702-95d9-75a4521e980d.png) @@ -60,7 +58,7 @@ INSERT DATA - Update Data -Changes to existing triples are performed as a delete operation followed by an insert operation in a single update request. +Changes to existing triples are performed as a delete operation followed by an insert operation in a single update request. The specification refers to this as `DELETE/INSERT` Sample SPARQL: update age to `36` for person `P001` @@ -84,6 +82,7 @@ DELETE WHERE :P001 ?p ?o . } ``` + Sample SPARQL: delete partial properties of person `P001` ```sparql @@ -93,6 +92,7 @@ DELETE WHERE :name ?name . } ``` + 2. SPARQL Query Call RPC `sparql_query` with SPARQL for `query` operations. @@ -103,7 +103,6 @@ curl -H "Content-Type: application/json" \ http://localhost:9933 ``` - ### Ecosystem Fit - Relation graph can effectively reduces the development threshold of building Web3 decentralized applications which contains large data. @@ -123,7 +122,7 @@ curl -H "Content-Type: application/json" \ - **Contact Name:** Joe Guo - **Contact Email:** pikajoe@relationlabs.ai -- **Website:** https://relationlabs.ai/ +- **Website:** ### Legal Structure @@ -132,7 +131,7 @@ curl -H "Content-Type: application/json" \ ### Team's experience -- Jessica Chang Founder +- Jessica Chang Founder Crypto and commodity trader @@ -150,40 +149,38 @@ Led team of 200+ members AsiaInfo, HP, AWS - Santry Huang CMO -Former CMO at Patract Labs +Former CMO at Patract Labs 9+ years of marketing and operation and experience - Ben Zhang Chief Software Architect -former core development engineer of IBM, AWS and other companies, +former core development engineer of IBM, AWS and other companies, 10+ years of back-end development experience, Problem solving Bigdata - Joe Guo CPO -former product leader of top blockchain companies, +former product leader of top blockchain companies, 6+ years of project experience in finance, logistics, social networking, games products ### Team Code Repos -- https://github.com/relationlabs -- https://github.com/gembin -- https://github.com/bbo268 +- +- +- ### Team LinkedIn Profiles (if available) -- Jessica Chang, Founder, https://www.linkedin.com/in/jessica-chang-a63313235/ -- Santry Huang, CMO, https://www.linkedin.com/in/santryhuang/ -- Yann， CTO， https://www.linkedin.com/in/yann-ren-361b91235/ -- Joe，CPO，https://www.linkedin.com/in/joe-guo-783780ab/ +- Jessica Chang, Founder, +- Santry Huang, CMO, +- Yann， CTO， +- Joe，CPO， ## Development Status :open_book: - -- We have finished a version on Internet computer.It is a graph database written in Rust and deployed on WASM.Ereryone can try it here(https://kziov-eaaaa-aaaag-aaaxa-cai.ic0.app/ic_graph_developer.html). - +- We have finished a version on Internet computer.It is a graph database written in Rust and deployed on WASM.Ereryone can try it here(). ## Development Roadmap :nut_and_bolt: @@ -191,7 +188,6 @@ former product leader of top blockchain companies, - **Full-Time Equivalent (FTE):** 2 FTE - **Total Costs:** 30,000 USD - ### Milestone 1 — Relation Graph deploy as pallet，contains insert,query,delete and update - **Estimated duration:** 1 month @@ -204,7 +200,6 @@ former product leader of top blockchain companies, | 0b. | Documentation | We will provide inline documentation and a tutorial of use and deploy pallet | | 0c. | Testing Guide | We will add unit tests to cover all basic logic.| | 1. | wasm package | We will create a wasm package that can deployed as pallet,contains insert,query,delete and update| - ### Milestone 2— Expand the basic functions of database，contains ACL,OGM and subgraph @@ -238,6 +233,3 @@ former product leader of top blockchain companies, ## Future Plans - Based on Relation Graph, we intend to provide a Web3 social DAPP build on substrate. - - - diff --git a/applications/Roloi.md b/applications/Roloi.md index 4afa0517cb0..0d179f2fc01 100644 --- a/applications/Roloi.md +++ b/applications/Roloi.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Roloi -- **Project Name:** Roloi - **Team Name:** NeoPower - **Payment Address:** 0x1f5CE2eDdaAAe75ff62729feE50F861bCDC0b62e (ETH Network -> **USDT**) - **Level:** 2 diff --git a/applications/RubeusKeeper.md b/applications/RubeusKeeper.md index 7640d19e6d9..41b8a9fec6f 100644 --- a/applications/RubeusKeeper.md +++ b/applications/RubeusKeeper.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Rubeus Keeper -- **Project Name:** Rubeus Keeper - **Team Name:** Bela Supernova - **Payment Address:** 0xC0d28794eA40Ce9b9F4B62a1B2Bb42FD34b7d305 (USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/RubyProtocol.md b/applications/RubyProtocol.md index f3a9dc46cd7..688cb1f33ab 100644 --- a/applications/RubyProtocol.md +++ b/applications/RubyProtocol.md @@ -1,57 +1,59 @@ -# Ruby Protocol - Open Grants Program +# Ruby Protocol - -* **Project:** Ruby Protocol -* **Proposer:** Ruby Protocol -* **Payment Address:** 0x5aBBe7b65c572b9f5Cc7655Ba4a1Acad0e892720 +- **Proposer:** Ruby Protocol +- **Payment Address:** 0x5aBBe7b65c572b9f5Cc7655Ba4a1Acad0e892720 ## Project Overview :page_facing_up: + ### Overview + #### Introduction This project will design and implement a fine-grained personal data monetization framework, which would serve as a second-layer/middleware protocol interacting with the substrate module. The framework will enable a data owner to enforce a fine-grained access control policy over his/her encrypted private data using functional encryption, and share predefined computation results over the private data with a data purchaser in exchange for economic compensation. The access control policy will be built into the substrate module, and the data monetization transaction will also execute via substrate module, which is why this solution is defined as a second-layer/middleware protocol. ### Project Details + #### Project Architecture -Functional encryption was originally proposed as a fine-grained access control mechanism over encrypted data [GPSW06]. A data owner encrypts a message `x` to generate ciphertext, which could be stored in an untrusted cloud server. The project might pay for the hosting expenses initially to jump-start the project, but we will gradually transfer the cost to the data owner since it would make sense for them to pay for their data monetization business. A data purchaser might wish to compute a function `f` over the encrypted message. With the consent of the data owner, a data purchaser would receive a secret key `sk_f` from a key distributor. The data purchaser can then use the private key `sk_f` to decrypt the ciphertext to compute `f(x)`. Note the data purchaser cannot retrieve any other information on the underlying message except the final decryption result `f(x)`. To prevent the data owner from accepting payment and then immediately removing their data from the cloud before the data purchaser receives the data, the data purchaser needs to retrieve the encrypted data before paying the owner. +Functional encryption was originally proposed as a fine-grained access control mechanism over encrypted data [GPSW06]. A data owner encrypts a message `x` to generate ciphertext, which could be stored in an untrusted cloud server. The project might pay for the hosting expenses initially to jump-start the project, but we will gradually transfer the cost to the data owner since it would make sense for them to pay for their data monetization business. A data purchaser might wish to compute a function `f` over the encrypted message. With the consent of the data owner, a data purchaser would receive a secret key `sk_f` from a key distributor. The data purchaser can then use the private key `sk_f` to decrypt the ciphertext to compute `f(x)`. Note the data purchaser cannot retrieve any other information on the underlying message except the final decryption result `f(x)`. To prevent the data owner from accepting payment and then immediately removing their data from the cloud before the data purchaser receives the data, the data purchaser needs to retrieve the encrypted data before paying the owner. Here is a more concrete example for functional encryption: the message here could be the user’s genomic data, and `f` could be a statistical analysis algorithm. The data purchaser could be a research institute intended to perform private statistical analysis over one’s genomic data. The secret key might be generated by the hospital that collects the users' genomic data or the data owner themselves. At the end of this transaction, the data owner will receive economic compensation for one's contribution to the computation result while the data purchaser will receive the statistical analysis results. In other cases, the data could also be one’s social network data and the function could be an analytics algorithm for online advertisement. We envision the monetary exchange between the data owner and purchaser will be executed as a substrate module. This project will implement a second-layer/middleware protocol running on Polkadot that enables individuals to monetize their private data in a fine-grained fashion. The delivery will include: -* A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. -* A substrate module that implements the encryption of the cryptographic keys of the functional encryption scheme and the associated zero-knowledge proof for its legitimacy. -* A micropayment scheme running on the Polkadot blockchain can allow individual users to monetize their data. -Here are the basic principles behind the overall architecture design of the fine-grained personal data monetization framework. We aim to keep the workload of the data owner minimum. This implies the online time of the data owner should be kept to a minimum. The optimal case would be the data owner is left alone after he generates and uploads the ciphertext. Ideally, the encryption workload of the data owner should also be kept as minimal as possible. The following scheme can be viewed as a generalization of the knowledge monetization scheme proposed in [TZLHJS2017]. +- A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. +- A substrate module that implements the encryption of the cryptographic keys of the functional encryption scheme and the associated zero-knowledge proof for its legitimacy. +- A micropayment scheme running on the Polkadot blockchain can allow individual users to monetize their data. -The general idea is shown in Fig. 1. A functional encryption scheme usually consists of four algorithms:`FE.Setup(1^\lambda)`, `FE.KeyGen(msk, f)`, `FE.Enc(mpk, x)` and `FE.Decrypt(Key_f, FE.Enc(mpk, x))`. At the beginning of the system, the key distributors run the `FE.Setup(1^\lambda)` algorithm to generate the master public key `mpk` and master secret key `msk`. Here `\lambda` denotes the security parameter. When a data owner wishes to sell his data, he encrypts his data `x` by running the `FE.Enc(mpk, x)` algorithm and uploads the output ciphertext `Enc(x)` to the untrusted cloud. He then specifies the pricing model with respect to different functions `f`’s in a substrate module SC, and posts it to the Polkadot blockchain. When a data purchaser intends to calculate `f(x)`, he will first generate a commitment of an appropriate amount of coin based on the pricing of the function `f` and his own public key `PK_P` as a transaction to call the module SC. +Here are the basic principles behind the overall architecture design of the fine-grained personal data monetization framework. We aim to keep the workload of the data owner minimum. This implies the online time of the data owner should be kept to a minimum. The optimal case would be the data owner is left alone after he generates and uploads the ciphertext. Ideally, the encryption workload of the data owner should also be kept as minimal as possible. The following scheme can be viewed as a generalization of the knowledge monetization scheme proposed in [TZLHJS2017]. + +The general idea is shown in Fig. 1. A functional encryption scheme usually consists of four algorithms:`FE.Setup(1^\lambda)`, `FE.KeyGen(msk, f)`, `FE.Enc(mpk, x)` and `FE.Decrypt(Key_f, FE.Enc(mpk, x))`. At the beginning of the system, the key distributors run the `FE.Setup(1^\lambda)` algorithm to generate the master public key `mpk` and master secret key `msk`. Here `\lambda` denotes the security parameter. When a data owner wishes to sell his data, he encrypts his data `x` by running the `FE.Enc(mpk, x)` algorithm and uploads the output ciphertext `Enc(x)` to the untrusted cloud. He then specifies the pricing model with respect to different functions `f`’s in a substrate module SC, and posts it to the Polkadot blockchain. When a data purchaser intends to calculate `f(x)`, he will first generate a commitment of an appropriate amount of coin based on the pricing of the function `f` and his own public key `PK_P` as a transaction to call the module SC.
          - +
          -The substrate module should return a receipt to the data purchaser, who will in turn present it to the key distributor. The key distributor, after verifying the receipt and the respective coin commitment, runs the `FE.KeyGen(msk, f)` algorithm to generate the function key `Key_f` for the data purchaser. +The substrate module should return a receipt to the data purchaser, who will in turn present it to the key distributor. The key distributor, after verifying the receipt and the respective coin commitment, runs the `FE.KeyGen(msk, f)` algorithm to generate the function key `Key_f` for the data purchaser. -Simultaneously, the distributor will send SC the encryption of `Key_f` under the data purchaser’s public key `PK_P`, denoted as `Enc_(PK_P)(Key_f)` and an associated zero-knowledge proof proving `Key_f` is indeed a well-formed function key corresponding to `f`. SC with the inputs from both the key distributor and data purchaser is then verified by the Polkadot blockchain. Once the verification for both sides passes, meaning the amount of the committed coin is sufficient to pay for the decryption result `f(x)` and the gas fee, and the associated zero-knowledge proof is correct, the payment will be released to the data owner. The data purchaser can then download the ciphertext and decrypt `f(x)` by running the `FE.Decrypt(Key_f, FE.Enc(mpk, x))` algorithm. +Simultaneously, the distributor will send SC the encryption of `Key_f` under the data purchaser’s public key `PK_P`, denoted as `Enc_(PK_P)(Key_f)` and an associated zero-knowledge proof proving `Key_f` is indeed a well-formed function key corresponding to `f`. SC with the inputs from both the key distributor and data purchaser is then verified by the Polkadot blockchain. Once the verification for both sides passes, meaning the amount of the committed coin is sufficient to pay for the decryption result `f(x)` and the gas fee, and the associated zero-knowledge proof is correct, the payment will be released to the data owner. The data purchaser can then download the ciphertext and decrypt `f(x)` by running the `FE.Decrypt(Key_f, FE.Enc(mpk, x))` algorithm. -Note once the verification of SC is passed, SC will execute and payment is released to the data owner instantaneously. To ensure fairness towards the data purchaser, the data owner should provide verifiable evidence to prove his data source. `FE.Enc(x)` is accompanied by a certified signature `Sig_D(FE.Enc(x))` to prove the data is coming from the right source and thus the data quality can be guaranteed. Here D denotes the private key of the data source. The data source could charge an extra service fee from the data owner when the data owner first meets the data source (goes to the hospital and does the test in the genomic computation example) and decides to join the monetization program. We note even though the data source (the hospital in the genomic computation example) is the one that produces the data, it doesn't necessarily mean that it owns the patients' data. For instance, according to [this report](https://www.forbes.com/sites/forbestechcouncil/2018/04/23/who-really-owns-your-health-data/?sh=1499f91d6d62), some states in the US explicitly give patients ownership of their health data. In other words, only the patient can dictate how the data should be monetized. Although it might be tempting to let the data source be representative of the data owners and handle the monetization of their private data, it would both go against both the law and the ethos of the project, which is to put the control of one's data back in the hands of the owner. +Note once the verification of SC is passed, SC will execute and payment is released to the data owner instantaneously. To ensure fairness towards the data purchaser, the data owner should provide verifiable evidence to prove his data source. `FE.Enc(x)` is accompanied by a certified signature `Sig_D(FE.Enc(x))` to prove the data is coming from the right source and thus the data quality can be guaranteed. Here D denotes the private key of the data source. The data source could charge an extra service fee from the data owner when the data owner first meets the data source (goes to the hospital and does the test in the genomic computation example) and decides to join the monetization program. We note even though the data source (the hospital in the genomic computation example) is the one that produces the data, it doesn't necessarily mean that it owns the patients' data. For instance, according to [this report](https://www.forbes.com/sites/forbestechcouncil/2018/04/23/who-really-owns-your-health-data/?sh=1499f91d6d62), some states in the US explicitly give patients ownership of their health data. In other words, only the patient can dictate how the data should be monetized. Although it might be tempting to let the data source be representative of the data owners and handle the monetization of their private data, it would both go against both the law and the ethos of the project, which is to put the control of one's data back in the hands of the owner. -The design of the underlying functional encryption scheme, where the private key should correspond to the function chosen by the data purchaser. Since the encryption of the private key should be presented as evidence (as shown in Fig. 1) and verified on the blockchain, the private key should be of minimum size, preferably constant size. To keep the workload of both the data owner and key distributor minimal, the encryption time and key generation time should be as short as possible. +The design of the underlying functional encryption scheme, where the private key should correspond to the function chosen by the data purchaser. Since the encryption of the private key should be presented as evidence (as shown in Fig. 1) and verified on the blockchain, the private key should be of minimum size, preferably constant size. To keep the workload of both the data owner and key distributor minimal, the encryption time and key generation time should be as short as possible. -There exist several functional encryption schemes with constant key size such as the one presented in [SC2017,CRH2015, RDGBP2019,B2017,MSHBM2019]. General predicate encryption allows the data owner to encrypt the raw data items tagged with various attributes, and a data purchaser to query different parts of the data repository using a function key corresponding to a predicate. Inner product predicate encryption [CGW2015] is a special kind of predicate encryption, where the data purchaser could retrieve the data records if the inner product of their attribute vector `y` and the predicate vector `x` specified by the data purchaser is equal to 0. For instance, the data purchaser could potentially ask for the data records corresponding to a conjunctive predicate such as “Age”AND“gender”AND“Income” from a personal data repository. One of the most efficient inner product encryption schemes [CGW2015] has a private key consisting of four elliptic curve group elements, and its key generation is dominated by four modular exponentiations. +There exist several functional encryption schemes with constant key size such as the one presented in [SC2017,CRH2015, RDGBP2019,B2017,MSHBM2019]. General predicate encryption allows the data owner to encrypt the raw data items tagged with various attributes, and a data purchaser to query different parts of the data repository using a function key corresponding to a predicate. Inner product predicate encryption [CGW2015] is a special kind of predicate encryption, where the data purchaser could retrieve the data records if the inner product of their attribute vector `y` and the predicate vector `x` specified by the data purchaser is equal to 0. For instance, the data purchaser could potentially ask for the data records corresponding to a conjunctive predicate such as “Age”AND“gender”AND“Income” from a personal data repository. One of the most efficient inner product encryption schemes [CGW2015] has a private key consisting of four elliptic curve group elements, and its key generation is dominated by four modular exponentiations. -While the predicate encryption allows the data purchaser to retrieve different parts of a database based on a predefined predicate, a more general functional encryption allows the data purchaser to calculate an arbitrary function over the input `x`. This project will focus on a slightly narrow set of functional encryption schemes: inner product encryption and quadratic polynomial function encryption [MSHBM2019]. In an inner product encryption scheme, for encryption of a vector `x`, the data purchaser with a private key corresponding to another vector `y` will be able to compute the inner product between `x` and `y`. On the other hand, in a quadratic polynomial functional encryption scheme, the data owner will encrypt two vectors `v_1 \in \mathbb{Z}_n` and `v_2 \in \mathbb{Z}_n`, a data purchaser with a secret key corresponding to a matrix `H \in \mathbb{Z}^{n*n}` is allowed to decrypt the quadratic product of `x_1, x_2`, and `H`, i.e., `x_1^T\cdot H \cdot x_2`. Both inner product encryption and quadratic polynomial functional encryption can support sophisticated privacy-preserving machine learning tasks, such as classification [LCFS2017,SGP2018] and neural networks [RDGBP2019]. +While the predicate encryption allows the data purchaser to retrieve different parts of a database based on a predefined predicate, a more general functional encryption allows the data purchaser to calculate an arbitrary function over the input `x`. This project will focus on a slightly narrow set of functional encryption schemes: inner product encryption and quadratic polynomial function encryption [MSHBM2019]. In an inner product encryption scheme, for encryption of a vector `x`, the data purchaser with a private key corresponding to another vector `y` will be able to compute the inner product between `x` and `y`. On the other hand, in a quadratic polynomial functional encryption scheme, the data owner will encrypt two vectors `v_1 \in \mathbb{Z}_n` and `v_2 \in \mathbb{Z}_n`, a data purchaser with a secret key corresponding to a matrix `H \in \mathbb{Z}^{n*n}` is allowed to decrypt the quadratic product of `x_1, x_2`, and `H`, i.e., `x_1^T\cdot H \cdot x_2`. Both inner product encryption and quadratic polynomial functional encryption can support sophisticated privacy-preserving machine learning tasks, such as classification [LCFS2017,SGP2018] and neural networks [RDGBP2019]. The benchmark results for various inner product encryption and quadratic polynomial function encryption schemes can be found in [MSHBM2019]. The private key of inner product encryption consists of one elliptic curve group element, which is of 256 bits under 128-bit level security. The key generation for a vector of 100 elements takes 0.4149s, and the encryption time for the data owner is around 0.2103s for a vector of the same size. The private key of quadratic polynomial functional encryption also only consists of one elliptic curve group element. The average key generation and encryption time for each coordinate of the message vector is 0.001s and 0.025s. In terms of the accompanied zero-knowledge proof scheme, the statement of the zero-knowledge proof scheme should be to convince the verifier that the encrypted content is a well-formed function key with regards to a predefined function in the module. Since the verification of the zero-knowledge proof should be verified by the blockchain, we need to make sure the verification is efficient and the proof size is as small as possible. The candidate zero-knowledge proof scheme for this is zk-snark implementation such as [ZeroPool](https://github.com/zeropoolnetwork/zeropool-substrate), which is an implementation of Groth16 scheme. The proof generation time is comparatively short for the previously mentioned encryption schemes since the respective statement (determined by the key generation algorithm and the public key encryption) is quite simple. -According to the pricing model of data monetization, a report presented by OECD [RRS2013] classifies the existing practical pricing models of personal data into two major categories: based on market valuation and individual valuation. The approach based on individual valuation suffers from the defect that the individual valuation of the private data is extremely context-dependent and cannot be measured with precision and certainty. The market-valuation-based approach can be further divided into the following sub-categories: market cap per data record, market prices for data, cost of a data breach, and data prices in illegal markets. +According to the pricing model of data monetization, a report presented by OECD [RRS2013] classifies the existing practical pricing models of personal data into two major categories: based on market valuation and individual valuation. The approach based on individual valuation suffers from the defect that the individual valuation of the private data is extremely context-dependent and cannot be measured with precision and certainty. The market-valuation-based approach can be further divided into the following sub-categories: market cap per data record, market prices for data, cost of a data breach, and data prices in illegal markets. -The approach based on market prices for data is particularly interesting given that data brokers usually publicly broadcast their asking prices for various personal data records. Our platform can easily aggregate and compare across various data brokers to use it as the proxy pricing model of the individual personal data record. One could further refine these data prices based on the queried function and adopt a fine-grained pricing approach used by DirectMail [MDJM2019]. They give an example where the base price per record is equal to $0.045 and the predicate-based price per record is equal to $0.0035 + $0 + $0.004 = $0.0075 (for example, calculated from the aforementioned conjunctive predicate). Thus, the total price per record for predicate encryption would be equal to $0.045 + $0.0075 = $0.0525. For the inner product encryption or quadratic polynomial function encryption, the price of the decryption result will exclude the base price of the record. +The approach based on market prices for data is particularly interesting given that data brokers usually publicly broadcast their asking prices for various personal data records. Our platform can easily aggregate and compare across various data brokers to use it as the proxy pricing model of the individual personal data record. One could further refine these data prices based on the queried function and adopt a fine-grained pricing approach used by DirectMail [MDJM2019]. They give an example where the base price per record is equal to $0.045 and the predicate-based price per record is equal to $0.0035 + $0 + $0.004 = $0.0075 (for example, calculated from the aforementioned conjunctive predicate). Thus, the total price per record for predicate encryption would be equal to $0.045 + $0.0075 = $0.0525. For the inner product encryption or quadratic polynomial function encryption, the price of the decryption result will exclude the base price of the record. -This will be one of the pricing strategies we adopt in phase 1 and phase 2 of our project. In the later development of our project, we will explore more algorithmic pricing approaches such as Automated Market Maker’s (AMMs), where the platform estimates how much the data purchaser is willing to pay for data of different qualities and determines the concrete data pricing model. +This will be one of the pricing strategies we adopt in phase 1 and phase 2 of our project. In the later development of our project, we will explore more algorithmic pricing approaches such as Automated Market Maker’s (AMMs), where the platform estimates how much the data purchaser is willing to pay for data of different qualities and determines the concrete data pricing model. #### Team Interest @@ -64,45 +66,50 @@ We will leverage the existing cryptographic library in the Polkadot ecosystem, s ##### Open API and SDK The ultimate goal of Ruby Protocol is to provide an essential open API and SDK from a high-level perspective with the above tools, fully powering the data monetization framework on Polkadot, including: -* A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. A substrate module that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. -* The client can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms. + +- A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. A substrate module that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. +- The client can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms. #### Ecosystem Fits -The existing internet economic model relies almost exclusively on the monetization of personal data. The recent scandals on the internet companies mishandling individual data such as Facebook’s Cambridge Analytica scandal have prompted many individuals to awaken to the fact that in the current internet economy they are the product and they need to regain control over their data. In fact, I would argue that the recently published privacy regulation such as GDPR or CCPA is the response to this urge. -Polkadot could act as an indispensable role to remove the middleman of the internet economy. A second-layer fine-grained personal data monetization framework based on Polkadot would potentially move Polkadot beyond a decentralized financial platform and enable Polkadot to play a central role in the next-generation data economy. It would also enable Polkadot to gain a moral high ground by freeing billions of web users from the control of monopoly middleman companies. +The existing internet economic model relies almost exclusively on the monetization of personal data. The recent scandals on the internet companies mishandling individual data such as Facebook’s Cambridge Analytica scandal have prompted many individuals to awaken to the fact that in the current internet economy they are the product and they need to regain control over their data. In fact, I would argue that the recently published privacy regulation such as GDPR or CCPA is the response to this urge. -The following is the reason why a cross-chain platform such as Polkadot is a perfect platform to implement a decentralized and transparent data monetization mechanism: -The monetary return of one single data monetization transaction tends to be small. The economic benefit to the data owner can only be noticeable when this type of micropayment happens frequently. However, the mental cost incurred by having to deal with frequent micropayment might render it undesirable. Substrate module as publicly verifiable, self-enforcing code could help amortize the mental cost. +Polkadot could act as an indispensable role to remove the middleman of the internet economy. A second-layer fine-grained personal data monetization framework based on Polkadot would potentially move Polkadot beyond a decentralized financial platform and enable Polkadot to play a central role in the next-generation data economy. It would also enable Polkadot to gain a moral high ground by freeing billions of web users from the control of monopoly middleman companies. -The substrate module will specify the types of computation the data purchaser is allowed to perform over the ciphertext. Since the same computation result could be of different values to different data purchasers, automatic payment based on substrate module could be used to enforce sophisticated pricing models to guarantee the maximum economic return for the data owner. +The following is the reason why a cross-chain platform such as Polkadot is a perfect platform to implement a decentralized and transparent data monetization mechanism: +The monetary return of one single data monetization transaction tends to be small. The economic benefit to the data owner can only be noticeable when this type of micropayment happens frequently. However, the mental cost incurred by having to deal with frequent micropayment might render it undesirable. Substrate module as publicly verifiable, self-enforcing code could help amortize the mental cost. -A publicly verifiable substrate module would not only help with the transparent enforcement of various privacy regulations such as General data protection regulation (GDPR) or California consumer privacy act (CCPA) but also ensure the fairness of data monetization transactions without the involvement of any middleman [TZLHJS17]. This is in stark contrast with the opaque business model of the existing internet economy where giant internet companies absorb all the economic benefits of personal data monetization. Our framework will let individuals regain control of their private data. +The substrate module will specify the types of computation the data purchaser is allowed to perform over the ciphertext. Since the same computation result could be of different values to different data purchasers, automatic payment based on substrate module could be used to enforce sophisticated pricing models to guarantee the maximum economic return for the data owner. + +A publicly verifiable substrate module would not only help with the transparent enforcement of various privacy regulations such as General data protection regulation (GDPR) or California consumer privacy act (CCPA) but also ensure the fairness of data monetization transactions without the involvement of any middleman [TZLHJS17]. This is in stark contrast with the opaque business model of the existing internet economy where giant internet companies absorb all the economic benefits of personal data monetization. Our framework will let individuals regain control of their private data. We all know the slogan “Data is the new oil”. According to alliedmarketresearch.com, the global data monetization market size was valued at $44869 in 2016, and is projected to reach at $370969 million by 2023, growing at a CAGR of 35.4% from 2017 to 2023. Even by capturing a small piece of this market, it would bring enormous economic benefits to the Polkadot ecosystem. -A second-layer fine-grained data monetization framework will also greatly expand the Polkadot community through attracting not only privacy-conscious users but also business partners hunger for high-quality data such as research institutes, hospitals, traditional financial institutes, etc. +A second-layer fine-grained data monetization framework will also greatly expand the Polkadot community through attracting not only privacy-conscious users but also business partners hunger for high-quality data such as research institutes, hospitals, traditional financial institutes, etc. There are three relevant projects: the first one is perhaps the Enigma project, a privacy protocol that enables the creation of decentralized applications that guarantee privacy. The protocol Enigma bases on is secure multi-party computation (MPC). The second one, Insights Network is a data exchange based on combining blockchain technology, substrate module, and MPC. It is based on the EOS blockchain and a custom MPC system. The third one, NuCypher is a cryptographic infrastructure for privacy-preserving applications. Its main technology is threshold proxy re-encryption and fully homomorphic encryption. None of these second-layer protocols are built for the Polkadot ecosystem. -There are several different ways of implementing an MPC protocol: threshold homomorphic encryption, garbled circuit, and secret sharing. The general idea of MPC is to outsource private data (either in the form of secret shares or homomorphic encryption) to a few separate computing parties so that they can perform confidential computation over the encrypted data. Directly applying MPC to fine-grained personal data monetization is problematic in the sense that once the data is outsourced, the data owner does not exert any control over what type of computation can be performed by the computing party. In other words, individual privacy is now at the mercy of these computing parties, which is against the human-centric ethos of fine-grained personal data monetization, where the access control policy should be defined by the data owner and enforced by the algorithm. On the other hand, functional encryption was specifically proposed and tailored for enforcing fine-grained access control over encrypted data. By allowing the data owner to define the access control policy, the owner has full control over what type of access the data purchaser can have over the encrypted personal data. The only decryption result the data purchaser will be able to retrieve is the predefined function evaluation. +There are several different ways of implementing an MPC protocol: threshold homomorphic encryption, garbled circuit, and secret sharing. The general idea of MPC is to outsource private data (either in the form of secret shares or homomorphic encryption) to a few separate computing parties so that they can perform confidential computation over the encrypted data. Directly applying MPC to fine-grained personal data monetization is problematic in the sense that once the data is outsourced, the data owner does not exert any control over what type of computation can be performed by the computing party. In other words, individual privacy is now at the mercy of these computing parties, which is against the human-centric ethos of fine-grained personal data monetization, where the access control policy should be defined by the data owner and enforced by the algorithm. On the other hand, functional encryption was specifically proposed and tailored for enforcing fine-grained access control over encrypted data. By allowing the data owner to define the access control policy, the owner has full control over what type of access the data purchaser can have over the encrypted personal data. The only decryption result the data purchaser will be able to retrieve is the predefined function evaluation. ## Team :busts_in_silhouette: + ### Team Members -* David Spade - Full-stack Software Engineer -* Kevin Hsu - Data Scientist -* Dylan Dewdney - Marketing Advisor -* Beni Issembert - Strategy Advisor +- David Spade - Full-stack Software Engineer +- Kevin Hsu - Data Scientist +- Dylan Dewdney - Marketing Advisor +- Beni Issembert - Strategy Advisor ### Team Website -* http://rubyprotocol.com/ +- ### Legal Structure -* Ruby Technology Ltd. is a company registered in the Cayman Islands. + +- Ruby Technology Ltd. is a company registered in the Cayman Islands. ### Team Experience + **David Spade** David Spade graduated from the University of Nottingham. He is a full-stack developer with 8 years of experience in software development. David also has deep knowledge in zero-knowledge algorithms and he is an expert in data science. @@ -116,44 +123,53 @@ Beni Issembert is a former Beam Privacy CMO, and currently works as Concordium C Dylan Dewdney is a longtime crypto enthusiast (2011). In 2017 he co-founded Harbour DAO, which became an open-standard set of tools for building governance structures and voting mechanisms on ERC-20. Later, as Chief Evangelist of Beam and Head of Growth for AdEx, he was a key part of their GTM and general growth strategies. Dylan is a respected peer among many different projects and areas of business.Dylan is also the project lead and CEO of DeData project Kylin Network. ### Team Code Repos -* https://github.com/Ruby-Protocol + +- ### Team Linkedin Profiles -* www.linkedin.com/in/dylan-dewdney -* www.linkedin.com/in/beniissembert -* www.linkedin.com/in/yingkaixu + +- www.linkedin.com/in/dylan-dewdney + +- www.linkedin.com/in/beniissembert +- www.linkedin.com/in/yingkaixu ## Development Roadmap :nut_and_bolt: + ### Overview -* **Total Estimated Duration:** 2 months -* **Full-time equivalent (FTE):** 3 FTE -* **Total Costs:** 30,000 DAI + +- **Total Estimated Duration:** 2 months + +- **Full-time equivalent (FTE):** 3 FTE +- **Total Costs:** 30,000 DAI #### Milestone 1 — Implement Cryptographic Modules -* **Estimated Duration:** 5 months -* **FTE:** 1 -* **Costs:** 10K DAI -The main deliverable of this milestone includes: -* A cryptographic library written in Rust that implements the inner product functional encryption and quadratic polynomial functional encryption. +- **Estimated Duration:** 5 months + +- **FTE:** 1 +- **Costs:** 10K DAI + +The main deliverable of this milestone includes: + +- A cryptographic library written in Rust that implements the inner product functional encryption and quadratic polynomial functional encryption. -* A substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. +- A substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. | **Number** | **Deliverable** | **Specification** | | ---------- | ------------------------------------- | ------------------------------------------------------------ | | 0a. | License | Apache License 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | -| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | -| 0d. | Article/Tutorial | We will publish a medium article that explains the functionality of the proposed cryptographic library and substrate pallet delivered in this milestone. +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Article/Tutorial | We will publish a medium article that explains the functionality of the proposed cryptographic library and substrate pallet delivered in this milestone. | 1. | Cryptographic modules | We will implement the cryptographic modules including inner product functional encryption and quadratic polynomial functional encryption [MSHBM2019] and the associated zero-knowledge proof [ZeroPool]. The cryptographic modules will be written in Rust and modified from the [rust version](https://github.com/dev0x1/functional-encryption-schemes) of [CiFEr library](https://github.com/fentec-project/CiFEr). We will build privacy-preserving classification and neural networks based on these modules. We will also implement a substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. | | 2. | Benchmark | Perform unit tests on the individual algorithms to ensure their safety. Benchmark on the gas cost and throughput of the proposed module. | | 3. | Docker | We will provide a dockerfile to demonstrate the usage of our modules. | #### Milestone 2 —— Client Implementation and Integration -* **Estimated Duration:** 1 month -* **FTE:** 2 -* **Costs:** 20K DAI +- **Estimated Duration:** 1 month +- **FTE:** 2 +- **Costs:** 20K DAI The main deliverable of the milestone is the client that can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms. @@ -161,17 +177,19 @@ The main deliverable of the milestone is the client that can trigger the aforeme | ---------- | ------------------------------------- | ------------------------------------------------------------ | | 0a. | License | Apache License 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | -| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Article/Tutorial | We will publish a medium article that explains the functionality of the proposed client and UI delivered in this milestone. | 1. | Client modules | We will implement the client to support the key distribution and decryption of the functional encryption scheme [MSHBM2019]. The client will also generate the transaction that can trigger the aforementioned cryptographic modules and the micropayment scheme [MDJM2019], such as the encrypted functional key and zero-knowledge proof. We will provide a basic UI to take inputs from the users for all these algorithms and receive the outputs. More specifically, the UI will enable the data owner to input the raw data to generate the signed ciphertext and upload it to the cloud server. The UI will also allow the data purchaser to retrieve the functional key from the key authority and the ciphertext from the cloud and then perform the decryption. The UI will also register a qualified data source and allow a data owner to join the data monetization program when he/she meets the data source and the data owners to request a signature from a registered source, which will then be verified on-chain. Finally, it will also allow these entities to interact with the substrate module with the inputs and outputs defined in our architecture. | | 2. | Benchmark | Perform unit tests on the individual algorithms to ensure their safety. Benchmark on the latency and usability of the proposed client functionalities. | | 3. | Docker | We will provide a dockerfile to demonstrate the usage of our modules. | ### Community Engagement -* **Bounty Program for General Community:** We will reward users who contribute positively to community building and content creation through an Ambassador Program. The community management team will be available 24/7 to answer questions. -* **Incentive Program for Data Monetization:** After the main functions are completed, we will provide incentives for users to monetize their data on our platform. This is an encouragement for users to provide the data and purchase the data. -* **Parachain Loan Offering Campaign:** We may hold a Parachain Loan Offering and reward users for helping our auction with Ruby Protocol tokens. -* **Affiliated Program of Cryptographic Infrastructure:** It is proven effective for user growth and can be integrated into Ruby’s cryptographic infrastructure. + +- **Bounty Program for General Community:** We will reward users who contribute positively to community building and content creation through an Ambassador Program. The community management team will be available 24/7 to answer questions. + +- **Incentive Program for Data Monetization:** After the main functions are completed, we will provide incentives for users to monetize their data on our platform. This is an encouragement for users to provide the data and purchase the data. +- **Parachain Loan Offering Campaign:** We may hold a Parachain Loan Offering and reward users for helping our auction with Ruby Protocol tokens. +- **Affiliated Program of Cryptographic Infrastructure:** It is proven effective for user growth and can be integrated into Ruby’s cryptographic infrastructure. ## Future Plans @@ -184,6 +202,7 @@ In phase 2, our goal is to deliver the micropayment scheme and enable the users Finally, our goal is to provide an essential open API and SDK from a high-level perspective with the above tools, fully powering the data monetization framework on Polkadot. ## Additional Information :heavy_plus_sign: + ### Reference [GPSW06] Goyal, V., Pandey, O., Sahai, A., & Waters, B. (2006, October). Attribute-based encryption for fine-grained access control of encrypted data. In Proceedings of the 13th ACM conference on Computer and communications security (pp. 89-98). @@ -196,11 +215,11 @@ Finally, our goal is to provide an essential open API and SDK from a high-level [B2017] Bourse, F. (2017). Functional encryption for inner-product evaluations (Doctoral dissertation). -[B2018] Vitalik Buterin, -https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477, +[B2018] Vitalik Buterin, +, 2018. -[BCTV2013] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct non-interactive zero knowledge for a von Neumann architecture. In Proceedings of the 23rd USENIX Security Symposium, Security '14. Available at http://eprint.iacr.org/2013/879. +[BCTV2013] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct non-interactive zero knowledge for a von Neumann architecture. In Proceedings of the 23rd USENIX Security Symposium, Security '14. Available at . [BMEB2016] Bataineh, A. S., Mizouni, R., El Barachi, M., & Bentahar, J. (2016, June). Monetizing Personal Data: A Two-Sided Market Approach. In ANT/SEIT (pp. 472-479). @@ -222,12 +241,4 @@ https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-t [SC2017] Agrawal, Shashank, and Melissa Chase. "Simplifying design and analysis of complex predicate encryption schemes." Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, Cham, 2017. [SGP2018] Sans, E.D., Gay, R., Pointcheval, D.: Reading in the dark: Classifying encrypted digits with functional encryption. IACR Cryptology ePrint Archive 2018, 206, (2018). -[TZLHJS2017] Florian Tramer, Fan Zhang, Huang Lin, Jean-Pierre Hubaux, Ari Juels, and Elaine Shi. ”Sealed-glass proofs: Using transparent enclaves to prove and sell knowledge.” In Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, pp. 19-34. IEEE, 2017. - - - - - - - - +[TZLHJS2017] Florian Tramer, Fan Zhang, Huang Lin, Jean-Pierre Hubaux, Ari Juels, and Elaine Shi. ”Sealed-glass proofs: Using transparent enclaves to prove and sell knowledge.” In Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, pp. 19-34. IEEE, 2017. diff --git a/applications/SEOR-code-less-smart-contract-platform.md b/applications/SEOR-code-less-smart-contract-platform.md index 7cfd500a4be..e84939c6b39 100644 --- a/applications/SEOR-code-less-smart-contract-platform.md +++ b/applications/SEOR-code-less-smart-contract-platform.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# SEOR code-less smart contract platform -* **Project Name:** SEOR code-less smart contract platform * **Team Name:** SEOR * **Payment Address:** 0x573e932F79a8846a058032454Ee7Fd7C6df7Dc41 * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/205#issuecomment-1168462194) diff --git a/applications/SaaS3.md b/applications/SaaS3.md index ee0de6ff0e1..4451de0e826 100644 --- a/applications/SaaS3.md +++ b/applications/SaaS3.md @@ -1,38 +1,38 @@ -# W3F Grant Proposal +# SaaS3 > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. -- **Project Name:** SaaS3 -- **Team Name:** SaaS3 Lab +- **Team Name:** SaaS3 Lab - **Payment Address(USDT):** 0x8341e551B0AE5E5905C20A112b123b5F797612f3 - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview :page_facing_up: ### Overview -#### Dilemma of web3 Ecosystem - With functionalities yet to become full-fledged, Web3.0 applications need a rethink of development stacks. -For instance, most of the web2 projects and dependencies are based on Java, C++, PHP, etc., while web3 requires another totally different technical stacks such as Solidity, Motoku, or Substrate on EVM / WASM which hinders web2 developers to build web3 applications. -![image](https://user-images.githubusercontent.com/95557343/157393726-c22c47d2-a4d0-4335-b890-29d6fad4417c.png) +#### Dilemma of web3 Ecosystem - With functionalities yet to become full-fledged, Web3.0 applications need a rethink of development stacks + +For instance, most of the web2 projects and dependencies are based on Java, C++, PHP, etc., while web3 requires another totally different technical stacks such as Solidity, Motoku, or Substrate on EVM / WASM which hinders web2 developers to build web3 applications. +![image](https://user-images.githubusercontent.com/95557343/157393726-c22c47d2-a4d0-4335-b890-29d6fad4417c.png) -SaaS3 project aims to deliver a fully decentralized software as a service (SaaS) network with highly scalable, crypto token incentivized and results in a solution that can serve as the application interface (API) layer for web3. -SaaS3 is devoted to transforming traditional web2 API to web3 dAPI by decentralized docker runtime (dRuntime). -Particularly, regardless of development stack differences, Linux-based Web2 APIs can be deployed on our platform for providing web3 services by decentralized APIs (dAPI). -Essentially, SaaS3 is an off-chain scaling technique of layer-2 which utilizes cheap off-chain docker computation to replace high-priced on-chain WASM / EVM runtime, while still remaining computation decentralization by delegated proof of stake (DPoS) consensus and on-chain zero knowledge proof. -Therefore, such layer-2 off-chain scaling is not only for computation price but technical development stacks compatible. +SaaS3 project aims to deliver a fully decentralized software as a service (SaaS) network with highly scalable, crypto token incentivized and results in a solution that can serve as the application interface (API) layer for web3. +SaaS3 is devoted to transforming traditional web2 API to web3 dAPI by decentralized docker runtime (dRuntime). +Particularly, regardless of development stack differences, Linux-based Web2 APIs can be deployed on our platform for providing web3 services by decentralized APIs (dAPI). +Essentially, SaaS3 is an off-chain scaling technique of layer-2 which utilizes cheap off-chain docker computation to replace high-priced on-chain WASM / EVM runtime, while still remaining computation decentralization by delegated proof of stake (DPoS) consensus and on-chain zero knowledge proof. +Therefore, such layer-2 off-chain scaling is not only for computation price but technical development stacks compatible. The SaaS3 project aims to decentralize computational providers and mint income-NFT to earn profits. The API creators could earn an income fee by holding those iNFT or selling them on NFT marketplace. -As a result, the SaaS3 project will bridge web2 APIs to web3 dAPIs to flourish web3 ecosystem and achieve creator economy in a decentralized and trust-minimized way. -This grant will allow us to develop several pallets to implement a parachain with substrate on Polkadot / Kusama. +As a result, the SaaS3 project will bridge web2 APIs to web3 dAPIs to flourish web3 ecosystem and achieve creator economy in a decentralized and trust-minimized way. +This grant will allow us to develop several pallets to implement a parachain with substrate on Polkadot / Kusama. SaaS3 as a part of Polkadot / Kusama / web 3 Ecosystem and has the following properties: - - Bridge - Monetize abundant web2 projects as decentralized web3 services in a very short time with extremely cheap cost. - - No Middleman - Cheap fee for dAPI users or Dapp developers compare with centralized SaaS products. - - Security - Improve the security for a system by PoS consensus and zero knowledge proof for miner network. Web3 dAPI are backed by token stakers (DPoS) with a reward and punishment mechanism. - - Reliability - Strengthen robustness for dAPI by computation decentralization and dRuntime redundancy of miners. - - Green - Save energy and reduce the cost by making use of spare computation resources for API computation. +- Bridge - Monetize abundant web2 projects as decentralized web3 services in a very short time with extremely cheap cost. +- No Middleman - Cheap fee for dAPI users or Dapp developers compare with centralized SaaS products. +- Security - Improve the security for a system by PoS consensus and zero knowledge proof for miner network. Web3 dAPI are backed by token stakers (DPoS) with a reward and punishment mechanism. +- Reliability - Strengthen robustness for dAPI by computation decentralization and dRuntime redundancy of miners. +- Green - Save energy and reduce the cost by making use of spare computation resources for API computation. ### Protocol Details @@ -40,28 +40,27 @@ SaaS3 as a part of Polkadot / Kusama / web 3 Ecosystem and has the following pro ![image](https://user-images.githubusercontent.com/95557343/159788632-250f04b6-b2b9-42c5-9927-6e4487aea8ef.png) - Decentralized docker runtime (dRuntime) is built on miner network which aims to execute dAPIs. Those dAPIs is created by API creators as a result of development labor. Computational node targets to setup the dRuntime, or better known as the 'miner', namely the party that performs the computational tasks. They are hereafter referred to as 'nodes' or 'miners'. The Dapp developer is the dAPI user, who sends requests and pays to access the dAPI. Their actions are detailed below. - - To access a web3 dAPI, users pay $SA3 tokens to nodes as the Gas fee and to software creators as the royalty fee. +- To access a web3 dAPI, users pay $SA3 tokens to nodes as the Gas fee and to software creators as the royalty fee. - - The node(s) are rewarded to execute dAPIs with dRuntime on their equipments. Importantly, each miner can run multiple dAPIs with dRuntime cache (dCache) to maximize the throughput. +- The node(s) are rewarded to execute dAPIs with dRuntime on their equipments. Importantly, each miner can run multiple dAPIs with dRuntime cache (dCache) to maximize the throughput. - - The Creator receives the royalty fee as the reward for their commitment to the docker development; they are the author of Web2 API codes. +- The Creator receives the royalty fee as the reward for their commitment to the docker development; they are the author of Web2 API codes. ![image](https://user-images.githubusercontent.com/95557343/159788719-f6fb785d-65ce-4f7c-a3cb-5b0226708895.png) +##### Security & Off-chain Miner Consensus -##### Security & Off-chain Miner Consensus - -- Miner security - To qualify, a miner or node is required to stake a particular amount of tokens as collateral (POS). Each request for API will trigger an on-chain zero-knowledge proof check (zkc), which determines whether the node is rewarded or punished. +- Miner security - To qualify, a miner or node is required to stake a particular amount of tokens as collateral (POS). Each request for API will trigger an on-chain zero-knowledge proof check (zkc), which determines whether the node is rewarded or punished. - API security - Similar to API3 insurance, API security is achieved via Delegation Proof of Staking (DPoS). Particularly, the API creator is required to stake an amount of tokens at the time of submitting the dAPI deployment. The amount is set at a default value in their first submission and is adjusted in proportion to the service income. Besides, the token holders are able to stake on the dAPIs as a collateral and share profits with API creator. The mechanism is established following the same vein of the concepts in Polkadot / Kusama, including staking, nomination, and validation. - -The process described above establishes a de facto safeguard mechanism, sheltering dAPI users from potential malfunctions of the computational node or the API service, and when available providing remedies in compensation. + +The process described above establishes a de facto safeguard mechanism, sheltering dAPI users from potential malfunctions of the computational node or the API service, and when available providing remedies in compensation. ##### Collateral and Sue Claims -In the case of a malfunction, the user detects the misperformance and assesses the damages and losses, and is able to lodge a sue claim published on the Court DAO. In supplement, the staked tokens or collaterals are 'locked' for a period, a mechanism to discourage stakers from 'front-running claims', i.e. withdrawing the staked token as soon as a miner or service malfunctions to evade claims. On the other hand, the litigant is required to stake funds to be able to make a claim, which elevates the cost of abuse. The Court DAO deliberates on the sue claim and decides whether a remedy should be made to the victimized dAPI user. Once a claim is passed in Court DAO, the amount of tokens as has been claimed will be transferred to the litigant in compensation. + +In the case of a malfunction, the user detects the misperformance and assesses the damages and losses, and is able to lodge a sue claim published on the Court DAO. In supplement, the staked tokens or collaterals are 'locked' for a period, a mechanism to discourage stakers from 'front-running claims', i.e. withdrawing the staked token as soon as a miner or service malfunctions to evade claims. On the other hand, the litigant is required to stake funds to be able to make a claim, which elevates the cost of abuse. The Court DAO deliberates on the sue claim and decides whether a remedy should be made to the victimized dAPI user. Once a claim is passed in Court DAO, the amount of tokens as has been claimed will be transferred to the litigant in compensation. The same mechanism also applies to the punishment meted out for the node(s) that malfunctioned with on-chain zkc. Such a reward-and-punishment mechanism encourages nodes to act in good faith and better service quality. Hence, a much lower risk of potential cyber threats such as the Sybil attack. @@ -87,108 +86,104 @@ The same mechanism also applies to the punishment meted out for the node(s) that 1. **Location Proof of Stake (LPoS) with zkc for Miners** Regarding the miner network, we deploy on-chain zero knowledge check (zkc) and adopt a location-based optimization for PoS consensus, thus improving the network throughput for off-chain dRuntime execution. Specifically, when a dAPI user sends a request, a list of miner candidates will be generated, consisting of 10 nodes in the closest locations, (e.g., determined by network latency) which are determined by network latency. Meanwhile, since all nodes are required to have staked a amount of tokens, nodes are ranked in a list of, for example, 100 according to the staked amount. 3 miners has to be among the leading token stake and the ten nearest to qualify for executing the request and receiving the rewards, while the on-chain zero-knowledge check (zkc) is carried out. Admittedly, the network may to some degree hurt tolerable security. Nevertheless, the dAPI user will be able to access not just at low net-latency but also backed by the PoS consensus with zkc (for more about zkc, please refer to 7 or 9). It should also be noted that node congestion is mitigated en passant. - + 2. **dRuntime** -dRuntime refers to a decentralized docker runtime which execute dAPIs in a network of distributed computing resources. It is essentially an off-chain technique to scaling up computation for on-chain runtime, such as WASM or EVM in Polkadot or Ethereum networks. +dRuntime refers to a decentralized docker runtime which execute dAPIs in a network of distributed computing resources. It is essentially an off-chain technique to scaling up computation for on-chain runtime, such as WASM or EVM in Polkadot or Ethereum networks. 3. **dCache** dRuntime cache is a 3-level caching mechanism to guarantee high performance and large throughput for dRuntime. - + 4. **SaaSDAO** SaaSDAO refers to the decentralized autonomous organization charged with governance duties. - + -5. **iNFT** +5. **iNFT** iNFT refers to a tradable income NFT that is minted when an API creator submits a docker image to create a dAPI. iNFT allows the API creator to earn royalty fee. 6. **Miner Network** The miner network is implemented by pallet-miner and consists of all the providers of computational capabilities. The network offer decentralized APIs which undertakes to execute containers to reply DeResponse for user's DeRequest. All docker images can be deployed on each miner. Thus, other nodes are called in replacement should any node break down. The 'redundancy' of computing nodes, which is at the miner-level, helps the SaaS3 maintain its decentralization features and remain robust. -7. **On-chain 3-person zero knowledge proof check (3-zkc) and rewards** +7. **On-chain 3-person zero knowledge proof check (3-zkc) and rewards** Each dAPI call will be executed by 3 miners. Therefore, the hash values generated following the three responses will be compared against each other for agreement. The 3-zkc is performed enabled by a callable, on-chain pallet-function. There are multiple scenarios, as follows. - The three hash values are in agreement. No one will being slashed. - Only two values are in agreement, the check still gains approval. Another miner is found inconsistent and will be slashed on its token stake. - There is no agreement among the three nodes. In this case, the API call returns failure. The gas fee is nonetheless consumed and has no refunds. No party will face slash or claim reward, as neither miner malfunctions nor dAPI bugs can be found attributable. However, the failure-logs are recorded on on-chain storage. The user could raise an issue to the creator to push for a new docker, or lodge a sue claim on Court DAO as a query for potential compensation from miners / creators. For more details, please refer to 9. 3-zkcg. 8. **Court DAO** -At Court DAO, the dAPI user can pay a fee for sue claims and, subject to the court's ruling, may claim compensation from miners / creators on SaaS3 DAO on grounds of any dAPI failure. To supplement the on-chain failure logs, the user is required to provide the details regarding the failure case, such as the input data and the version of the failed API (docker image version). The Jury consists of top 101 largest staked API creators who are open source developers and active on DAO events. Members of the Jury can download the same version docker image and retest the failure case to investigate the failure cause. The on-chain failure log is available for jury members. +At Court DAO, the dAPI user can pay a fee for sue claims and, subject to the court's ruling, may claim compensation from miners / creators on SaaS3 DAO on grounds of any dAPI failure. To supplement the on-chain failure logs, the user is required to provide the details regarding the failure case, such as the input data and the version of the failed API (docker image version). The Jury consists of top 101 largest staked API creators who are open source developers and active on DAO events. Members of the Jury can download the same version docker image and retest the failure case to investigate the failure cause. The on-chain failure log is available for jury members. Jury will have the following options given the on-chain log records and local test results. - Reject - The user's sue claim is rejected, with no compensation, and the sue fee will not be refunded. Such a ruling may be on the grounds such as forged evidence and unreasonable amount of claims. Terms and conditions and regulations of SaaSDAO apply. - Approve - - Miner malfunction: + - Miner malfunction: - Which miners should be slashed. (This is multiple choices refer to on-chain log): - Miner1, Miner2, or Miner3 - Slash the dAPI in terms of drawbacks or bugs. - 9. **3-zkc and gas calculation algorithm (3-zkcg)** -We will provide a protocol / software which is similar with [AWS Lambda API Pricing](https://aws.amazon.com/lambda/pricing/) for miner, but replace dollar unit with gas. In SaaS3, miners should monitor each container's resource usage by our software to calculate gas usage i.e., `gas_used` for once dAPI call. `rewards=gas_used*gas_price` gas_used is defined by following process with 3-zkc. Here, we illustrate the algorithm to show the procedure, a user request with `gas_limit` is sent to three miners `m1,m2,m3` at time `t=0` with user-set maximum timeout `Tmax`, there will be following scenarios: - - If after timeout `Tmax`, no response is received, go to the failure state. - - Else, got `m1` response `r1` with reported gas `g1` at time `t1`, reset timeout `Tmax=max(2*t1, Tmax)`. - - If after timeout `Tmax`, go to failure state. - - Else, got `m2` response `r2` with reported gas `g2` at time `t2`, zkc will be conducted to confirm whether `r1=r2` - - `r1=r2` return `r1` to user and distribute `rewards=min(g1,g2) * gas_price` to `m1` with `(1-g1/(g1+g2)) * rewards` and to `m2` with `(1-g2/(g1+g2))*rewards` which means the lower `gas report`, the more rewards. - - `r1!=r2` reset timeout `Tmax=max(2*t2, Tmax)` - - If after timeout `Tmax`, go to failure state. - - Else, got `m3` response `r3` with reported gas `g3` at time `t3`, zkc will be conducted to confirm whether `r3=r1` or `r3=r2` - - If `r1!=r2!=r3`, go to failure state. - - Else, two conditions - - `r3=r1`, return `r1` to user and distribute `rewards=min(g1, g3) * gas_price` to `m1` with `(1-g1/(g1+g3)) * rewards` and to `m3` with `(1-g3/(g1+g3))*rewards`. `m2` will be slashed. - - `r3=r2`, return `r2` to user and distribute `rewards=min(g2, g3) * gas_price` to `m2` with `(1-g2/(g2+g3)) * rewards` and to `m3` with `(1-g3/(g2+g3))*rewards`. `m1` will be slashed. - - Failure state: reply user `error: dAPI fail` and charge gas fee as `gas_mean * gas_price`, where `gas_mean` is the average gas for that dAPI in the history. Neither three miners will be slashed, since in such case, it hard to determine whether the dAPI has bugs. The user could raise an issue/sue to Creator/CourtDAO to acquire compensation based on above on-chain records. If the miners notice some weird slashes with on-chain evidence, miners could raise sue to CourtDAO with their proof (e.g., give an IPFS docker image path which is the same version as creator submitted) to acquire claims and slash dAPI with acceptance from Court DAO. - -a0e9fb71f04ea16161f09ca17048e72 +We will provide a protocol / software which is similar with [AWS Lambda API Pricing](https://aws.amazon.com/lambda/pricing/) for miner, but replace dollar unit with gas. In SaaS3, miners should monitor each container's resource usage by our software to calculate gas usage i.e., `gas_used` for once dAPI call. `rewards=gas_used*gas_price` gas_used is defined by following process with 3-zkc. Here, we illustrate the algorithm to show the procedure, a user request with `gas_limit` is sent to three miners `m1,m2,m3` at time `t=0` with user-set maximum timeout `Tmax`, there will be following scenarios: +- If after timeout `Tmax`, no response is received, go to the failure state. +- Else, got `m1` response `r1` with reported gas `g1` at time `t1`, reset timeout `Tmax=max(2*t1, Tmax)`. + - If after timeout `Tmax`, go to failure state. + - Else, got `m2` response `r2` with reported gas `g2` at time `t2`, zkc will be conducted to confirm whether `r1=r2` + - `r1=r2` return `r1` to user and distribute `rewards=min(g1,g2) * gas_price` to `m1` with `(1-g1/(g1+g2)) * rewards` and to `m2` with `(1-g2/(g1+g2))*rewards` which means the lower `gas report`, the more rewards. + - `r1!=r2` reset timeout `Tmax=max(2*t2, Tmax)` + - If after timeout `Tmax`, go to failure state. + - Else, got `m3` response `r3` with reported gas `g3` at time `t3`, zkc will be conducted to confirm whether `r3=r1` or `r3=r2` + - If `r1!=r2!=r3`, go to failure state. + - Else, two conditions + - `r3=r1`, return `r1` to user and distribute `rewards=min(g1, g3) * gas_price` to `m1` with `(1-g1/(g1+g3)) * rewards` and to `m3` with `(1-g3/(g1+g3))*rewards`. `m2` will be slashed. + - `r3=r2`, return `r2` to user and distribute `rewards=min(g2, g3) * gas_price` to `m2` with `(1-g2/(g2+g3)) * rewards` and to `m3` with `(1-g3/(g2+g3))*rewards`. `m1` will be slashed. +- Failure state: reply user `error: dAPI fail` and charge gas fee as `gas_mean * gas_price`, where `gas_mean` is the average gas for that dAPI in the history. Neither three miners will be slashed, since in such case, it hard to determine whether the dAPI has bugs. The user could raise an issue/sue to Creator/CourtDAO to acquire compensation based on above on-chain records. If the miners notice some weird slashes with on-chain evidence, miners could raise sue to CourtDAO with their proof (e.g., give an IPFS docker image path which is the same version as creator submitted) to acquire claims and slash dAPI with acceptance from Court DAO. +a0e9fb71f04ea16161f09ca17048e72 ### Game theory Proof for 3-zkc algorithm with Nash Equilibrium Convergence ### Both Miner1,Miner2, and Miner3 will choose loyalty. - - - + ### Technical Implementation Diagram -We will implement 5 pallets: `pallet-entity`, `pallet-dAPI`, `pallet-DAO`, `pallet-miner`, and `pallet-stake` where `pallet-dAPI` is the core component of the project. -![image](https://user-images.githubusercontent.com/95557343/159320880-a6fc9d62-5cc2-457e-9797-11db72edf352.png) +We will implement 5 pallets: `pallet-entity`, `pallet-dAPI`, `pallet-DAO`, `pallet-miner`, and `pallet-stake` where `pallet-dAPI` is the core component of the project. +![image](https://user-images.githubusercontent.com/95557343/159320880-a6fc9d62-5cc2-457e-9797-11db72edf352.png) ### Ecosystem Fit - Although web2 applications are highly dependent on centralized libraries and technical stack, they have a potential case of monetization if migrated to web3 as decentralized web3 dAPI through SaaS3 protocol. - SaaS3 cloud could be a competitive alternative to centralized SaaS / API providers such as [Salesforce](https://appexchange.salesforce.com), [Microsoft Azure](https://docs.microsoft.com/en-us/rest/api/azureml/) and [Google AI](https://cloud.google.com/products/ai). - SaaS3 brings millions of dAPI/Dapp users, providers of computing resources and users into a harmony and an organic ecosystem, with lowered costs and reliable services. SaaS3 aims to become the world's largest decentralized API platform based on Polkadot / Kusama to provide high-quality dAPIs / Dapps at extremely affordable prices. -- SaaS holds potential for interaction with other parachains of Polkadot / Kusama. SaaS3's dAPIs can also be utilized as computation services for other parachain's specific usage such as AI-related recognition or game-AI algorithms. +- SaaS holds potential for interaction with other parachains of Polkadot / Kusama. SaaS3's dAPIs can also be utilized as computation services for other parachain's specific usage such as AI-related recognition or game-AI algorithms. Similar Projects: -- **Livepeer** https://livepeer.org/ It provides a video encoding service instead of general web3 SaaS. -- **API3** https://api3.org/ Its dAPI as decentralized oracle to provide off-chain data streaming for smart contracts instead of computation tasks to offer a SaaS in web3. - +- **Livepeer** It provides a video encoding service instead of general web3 SaaS. +- **API3** Its dAPI as decentralized oracle to provide off-chain data streaming for smart contracts instead of computation tasks to offer a SaaS in web3. SaaS market in Dapp, web3.0, and Metaverse: -- **Software Services** For example, the softwares on [Salesforce](https://appexchange.salesforce.com), Office365, Grammarly. -- **AI Services** Speech2Text, Voice2Text, Image Recognition, UGC-NFT Recognition, Marketing Analysis, Algorithm Recommendation, Bot-AI, Game-AI, Reinforcement Learning, and Behavior Analysis. +- **Software Services** For example, the softwares on [Salesforce](https://appexchange.salesforce.com), Office365, Grammarly. +- **AI Services** Speech2Text, Voice2Text, Image Recognition, UGC-NFT Recognition, Marketing Analysis, Algorithm Recommendation, Bot-AI, Game-AI, Reinforcement Learning, and Behavior Analysis. ### Designs / Mock-ups + ![6742e6c196c0ec2354f3e65474c0dd7](https://user-images.githubusercontent.com/95557343/155807321-3d96b3a6-f6c1-4b64-9411-3d75bd7eceb5.png) ![a07096c685597b9faaa8de4bce9956c](https://user-images.githubusercontent.com/95557343/155807345-fd92a0aa-1d5f-44ea-a57a-4f1ec8a4f70c.png) - ## Team :busts_in_silhouette: ### Team members + The core team members are top Ph.Ds in computer science who are technical and experienced. -- **Steven** is a Ph.D. in artificial intelligence and vice president of SaaS3 to build dRuntime on p2p network and financing-related works. Currently, he is an AI researcher and blockchain developer. He has written computer programs since he was 14 and got many hackathon awards in the past. +- **Steven** is a Ph.D. in artificial intelligence and vice president of SaaS3 to build dRuntime on p2p network and financing-related works. Currently, he is an AI researcher and blockchain developer. He has written computer programs since he was 14 and got many hackathon awards in the past. - **Rocky** is the CTO of SaaS3 undertakes SaaS3 protocol design. Currently, he is the presidential postdoctoral fellow in NTU and chief scientist in Singapore Smart City Project. Previously, he was an AI researcher at UCB. Besides, he is also a visiting lecture professor of NTU, NUS. He is also the winner of over 10 hackathons. @@ -199,13 +194,11 @@ The core team members are top Ph.Ds in computer science who are technical and ex - **Laekshan** was a software engineer in a world-leading company. He is also an expert in IoT development. He has mined bitcoin since 2015. Therefore, he has a lot of experience in crypto mining and market analysis. - - ### Contact - **Contact Name:** Rocky Yang - **Contact Email:** contact@saas3.io -- **website:** https://www.saas3.io +- **website:** ### Legal Structure @@ -214,27 +207,27 @@ development. He has mined bitcoin since 2015. Therefore, he has a lot of experie ### Team Code Repos -- https://github.com/SaaS3DAO/ -- https://github.com/SaaS3DAO/DeAIMainNet -- https://github.com/SaaS3DAO/non-api-nft -- https://github.com/SaaS3DAO/substrate-node-template -- https://github.com/SaaS3DAO/substrate +- +- +- +- +- GitHub accounts of all team members. -- https://github.com/isrugeek -- https://github.com/Marsrocky -- https://github.com/qinwang-ai -- https://github.com/ChinW -- https://github.com/Deslate -- https://github.com/kkazuha -- https://github.com/hugoycj +- +- +- +- +- +- +- ### Team LinkedIn Profiles (if available) -- https://www.linkedin.cn/injobs/in/israel-goytom-66713011b -- https://www.linkedin.cn/injobs/in/jianfei-yang-55560386/ -- https://www.linkedin.com/in/steven-wong-3b015079/ +- +- +- ## Development Roadmap :nut_and_bolt: @@ -244,14 +237,12 @@ GitHub accounts of all team members. - **Full-Time Equivalent (FTE):** 5 - **Total Costs:** 45500 USDT -### Milestone 1 — SaaS3 Documentation, pallet-entity, pallet-service, pallet-stake, +### Milestone 1 — SaaS3 Documentation, pallet-entity, pallet-service, pallet-stake - **Estimated duration:** 2.5 month - **FTE:** 4 - **Costs:** 24000 USD - - | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0| @@ -259,15 +250,15 @@ GitHub accounts of all team members. | 0c. | Testing Guide | We will provide a full test suite and guide for dAPIs usage for `pallet-dAPI`, token stake for `pallet-stake`. `pallet-entity` will be tested for dAPI usage and payment.| | 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 (what was done/achieved as part of the grant). (Content, language and medium should reflect our target audience described above.) -| 1. | pallet-entity| [pallet_assets](https://crates.io/crates/pallet-assets) is utilized for implementation with a minor change to fit SaaS3 project. An user and creator both can be implemented as entity. They are same in implementation perspective. | -| | Functions | No public function | -| 2. | pallet-dAPI| `pallet-dAPI` is core implementation of SaaS3 project which is a key middle ware and interacted a lot with other pallets' functions. A dAPI is also a iNFT to indicate the beneficial right for API creator. iNFT related part is implemented based on pallet-uniques. | -| | Functions| 1). `pub fn subscribe_dAPI(eid:u32, iNFT_id:u64, timespan:u256, count:u256) ` dAPI user call this function to pay token to subscribe dAPI.
          2). `pub fn create_dAPI(eid:u32, pid:u32)` Creator's docker image will be deployed as a dAPI.
          3). `pub fn use_dAPI(eid:u32, ip_address:Vec, iNFT_id:u64)` dAPI user call this function to allocate reliable miners to run dAPI.
          4). `fn check_dAPI(eid:u32, iNFT_id:u64)` The function can automatically check whether the dAPI is available for usage.| -| | Storage| `ServiceList get(fn iNFT_list): map hasher(blake2_128_concat) u32 => Vec;`
          `SubscriptionList get(fn subscription_list): map hasher(blake2_128_concat) u32 => Vec;`
          `Usages get(fn get_usages): map hasher(blake2_128_concat) u32 => Vec; `| -| | Struct| `pub struct iNFT`
          `pub struct Subscription`
          `pub struct Usage`| +| 1. | pallet-entity| [pallet_assets](https://crates.io/crates/pallet-assets) is utilized for implementation with a minor change to fit SaaS3 project. An user and creator both can be implemented as entity. They are same in implementation perspective. | +| | Functions | No public function | +| 2. | pallet-dAPI| `pallet-dAPI` is core implementation of SaaS3 project which is a key middle ware and interacted a lot with other pallets' functions. A dAPI is also a iNFT to indicate the beneficial right for API creator. iNFT related part is implemented based on pallet-uniques. | +| | Functions| 1). `pub fn subscribe_dAPI(eid:u32, iNFT_id:u64, timespan:u256, count:u256)` dAPI user call this function to pay token to subscribe dAPI.
          2). `pub fn create_dAPI(eid:u32, pid:u32)` Creator's docker image will be deployed as a dAPI.
          3). `pub fn use_dAPI(eid:u32, ip_address:Vec, iNFT_id:u64)` dAPI user call this function to allocate reliable miners to run dAPI.
          4). `fn check_dAPI(eid:u32, iNFT_id:u64)` The function can automatically check whether the dAPI is available for usage.| +| | Storage| `ServiceList get(fn iNFT_list): map hasher(blake2_128_concat) u32 => Vec;`
          `SubscriptionList get(fn subscription_list): map hasher(blake2_128_concat) u32 => Vec;`
          `Usages get(fn get_usages): map hasher(blake2_128_concat) u32 => Vec;`| +| | Struct| `pub struct iNFT`
          `pub struct Subscription`
          `pub struct Usage`| | 3. | pallet-stake| This pallet implements rewards and slashes related functions for token stakers to stake their tokens to services for DPoS consensus. [pallet-staking](https://crates.io/crates/pallet-staking) will be utilized for initial implementation and we will finely package it into our pallet-stake. | -| | Functions|1). `pub fn stake(eid:u32, sid:u32, credits:u32) ` User call this function to stake their credit to a dAPI as collateral.
          2). `pub fn stake queryStake(eid:u32, sid:u32)` It returns how many tokens is staked on a dAPI for a specific entity.
          3). `pub fn queryTotStake(eid:u32, mid:u32)` It returns the total staked tokens for a dAPI.
          4). `pub fn withdraw(eid:u32, sid:u32, credits:u32) ` Staker call this function to withdraw their tokens from dAPI. | -| | Storage|`MinerCollateral get(fn get_miner_collateral): map hasher(blake2_128_concat) u32 => u32;` | +| | Functions|1). `pub fn stake(eid:u32, sid:u32, credits:u32)` User call this function to stake their credit to a dAPI as collateral.
          2). `pub fn stake queryStake(eid:u32, sid:u32)` It returns how many tokens is staked on a dAPI for a specific entity.
          3). `pub fn queryTotStake(eid:u32, mid:u32)` It returns the total staked tokens for a dAPI.
          4). `pub fn withdraw(eid:u32, sid:u32, credits:u32)` Staker call this function to withdraw their tokens from dAPI. | +| | Storage|`MinerCollateral get(fn get_miner_collateral): map hasher(blake2_128_concat) u32 => u32;` | | 4. | UI & Frontend | This part is implemented by [substrate front-end template](https://github.com/substrate-developer-hub/substrate-front-end-template) The frontend and UI of user-side will be finished in this milestone. | ### Milestone 2 — Documentation and tutorial for miner and DAO. Development of pallet-miner and pallet-DAO @@ -284,34 +275,33 @@ GitHub accounts of all team members. | 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 (what was done/achieved as part of the grant). (Content, language and medium should reflect our target audience described above). | | 1. | pallet-miner | The pallet implements on-chain related things for miner to compute off-chain docker runtime. The computational power providers or miners in the network provide dAPI which aim to execute docker runtime to reply user's dRequest. Each docker image can be generally deployed on any miners. The pallet contains logic with off-chain softwares / models executions. 3-zkc related logics also will be implemented in this pallet. | -| | Functions | 1). `pub fn deploy(eid:u32, mid:u32, iNFT_id:u64)` The function is utilized to deploy one dAPI (ie., iNFT) on a specific miner and build off-chain connection to the dAPI user.
          2). `pub fn docker_manager()` It is only called at the first time when the miner connects to the blockchain to start a off-chain computation resource management related things such as 3-level dCache dispatch.
          3). `pub fn modify_miner_params(mid:u32, args:Vec)` It is an optional interface for miner to modify some on-chain parameters for adjustment computation. The implementation will be very careful to cause any security issues. 4). `fn distribute_rewards()` It can distribute Gas fee to miners| -| | Struct| `pub struct MinerParams`
          `pub struct EntityData`
          `pub struct EntityRuntime`| -| | Storage | `MinerParams get(fn get_miner_params): map hasher(blake2_128_concat) u32 => MinerParams;`
          `EntityData get(fn get_entity_data): map hasher(blake2_128_concat) u32 => Vec;`
          `EntityRuntime get(fn get_entity_runtime): map hasher(blake2_128_concat) u32 => Vec;`| +| | Functions | 1). `pub fn deploy(eid:u32, mid:u32, iNFT_id:u64)` The function is utilized to deploy one dAPI (ie., iNFT) on a specific miner and build off-chain connection to the dAPI user.
          2). `pub fn docker_manager()` It is only called at the first time when the miner connects to the blockchain to start a off-chain computation resource management related things such as 3-level dCache dispatch.
          3). `pub fn modify_miner_params(mid:u32, args:Vec)` It is an optional interface for miner to modify some on-chain parameters for adjustment computation. The implementation will be very careful to cause any security issues. 4). `fn distribute_rewards()` It can distribute Gas fee to miners| +| | Struct| `pub struct MinerParams`
          `pub struct EntityData`
          `pub struct EntityRuntime`| +| | Storage | `MinerParams get(fn get_miner_params): map hasher(blake2_128_concat) u32 => MinerParams;`
          `EntityData get(fn get_entity_data): map hasher(blake2_128_concat) u32 => Vec;`
          `EntityRuntime get(fn get_entity_runtime): map hasher(blake2_128_concat) u32 => Vec;`| | 2. | pallet-DAO | A DAO of judgement court, dAPI user raise sue to determine the punishment of malfunction miners / services and return sue claimed tokens to dAPI user.| -| |Functions |`pub fn submit_sue(eid:u32)` dAPI User submit sue claims for malfunction.
          `pub fn vote_sue(eid:u32, sid:u32)` Jury evaluates and votes the sue submission to determine punishment.
          `pub fn process_sue(sid:u32)` Process the accepted sue claims of dAPI user to slash malfunction miner / dAPI. The tokens will be paid to dAPI user and treasury with a ratio. | +| |Functions |`pub fn submit_sue(eid:u32)` dAPI User submit sue claims for malfunction.
          `pub fn vote_sue(eid:u32, sid:u32)` Jury evaluates and votes the sue submission to determine punishment.
          `pub fn process_sue(sid:u32)` Process the accepted sue claims of dAPI user to slash malfunction miner / dAPI. The tokens will be paid to dAPI user and treasury with a ratio. | | | Struct| `pub struct Sue` | | Storage| `SueList get(fn get_sue_list): map hasher(blake2_128_concat) u32 => Vec;` | 4. | UI & Frontend | This part is implemented by [substrate front-end template](https://github.com/substrate-developer-hub/substrate-front-end-template). The frontend web interface contains DAO procedures related functions which including user sue judgement. A special document website is developed to guide entities to participant DAO events. | ## Future Plans -- Initially, the parathreads will be utilized to connect the relay chain. Once the project goes well, we will participate slot auction. +- Initially, the parathreads will be utilized to connect the relay chain. Once the project goes well, we will participate slot auction. - Continue developing and polishing the project to flourish SaaS3 ecosystem to burst the web3 world based on Polkadot / Kusama / Substrate multi-chain system. - Provide more reliable efficient computation service which can run Polkadot / Kusama validator dockers. - ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** web3 Foundation Website **Related Files** -- PitchDeck: https://www.saas3.io/file/PitchDeck_SaaS3.pdf -- SaaS3 website: https://saas3.io -- iNFT Demo (move to RMRK standard soon): https://saas3.io/non-api-nft -- Whitepaper(Beta Version): https://www.saas3.io/file/SaaS3Whitepaper.pdf +- PitchDeck: +- SaaS3 website: +- iNFT Demo (move to RMRK standard soon): +- Whitepaper(Beta Version): **Other Grants** diff --git a/applications/Shivarthu.md b/applications/Shivarthu.md index 73a7c2724da..36976e4adad 100644 --- a/applications/Shivarthu.md +++ b/applications/Shivarthu.md @@ -1,14 +1,12 @@ -# W3F Open Grant Proposal +# Shivarthu > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. > > See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/#pencil-process) on how to submit a proposal. -* **Project Name:** Shivarthu * **Team Name:** Reaudito * **Payment Address:** 0x7e30FB962f951ef78D901865F87DD036fc5aa946 (DAI) - > ⚠️ *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.* ## Project Overview :page_facing_up: @@ -22,58 +20,60 @@ If this is an application for a follow-up grant (the continuation of an earlier, Shivarthu: The blockchain-based decentralized governance system. Democracy is about fair and equal treatment of everyone in a country. But it becomes unrealistic to achieve when political parties have their conflict of interest, and leaders don’t have the expertise to make evidence-based policies and neither have the skill and manpower for solving problems that surround our society and ecosystem. The new fair democracy provides an elegant way of governance that separates the representative responsibility according to their specialization and can grow into any complexity. The governance is divided into various departments, and each department is supervised by representatives with expertise in the field. Voters are rational and need to have enough knowledge about the departments and the department problems, in order to vote for the selecting representatives of a department. The selection process of representatives is “difficult in and easy out”, which allows only utilitarian actors to hold the responsibility, weeding out frivolous ones. -https://shivarthu.reaudito.com/paper/Shivarthu_whitepaper.pdf + Shivarthu will be build on Substrate. Our democracy has many challenges, blockchain can provide a way to tackle those challenges by minimizing trust through game theory. That made our team interested in creating this project. - ### Project Details -Project Github link: https://github.com/amiyatulu/shivarthu +Project Github link: +#### Departments -#### Departments: The governance is divided into many departments like education, infrastructure, health, community service for every locality. -#### Expertise evaluation of representatives : -Voters and especially representatives need to have some experience or expertise in the department. Experience is required because education about the department leads to better decision making. -Their experience is evaluated by schelling game. + +#### Expertise evaluation of representatives + +Voters and especially representatives need to have some experience or expertise in the department. Experience is required because education about the department leads to better decision making. +Their experience is evaluated by schelling game. portfolio -#### Schelling Game: +#### Schelling Game + In this project, the Schelling game is used for experise evaluation and review of projects. We use a modification of Schelling game named score Schelling game for fund distribution of projects. -Juror applies for making a decision like whether the required experience can be accepted or review quality of projects is acceptable. The probability of being drawn as a juror is proportional to the amount of tokens a juror stakes. The higher the amount of tokens he stakes, the higher the probability that he will be drawn as a juror. Also, jurors are drawn randomly. This protects the system from sybil attacks. +Juror applies for making a decision like whether the required experience can be accepted or review quality of projects is acceptable. The probability of being drawn as a juror is proportional to the amount of tokens a juror stakes. The higher the amount of tokens he stakes, the higher the probability that he will be drawn as a juror. Also, jurors are drawn randomly. This protects the system from sybil attacks. We will use the substrate randomness trait for generating a random number. -https://substrate.dev/recipes/randomness.html -Then jurors will vote for their decision using the commit and reveal scheme. In the commit phase, they submit the hash of the vote string. Then, in the reveal phase, they submit the hash and the vote string. If the vote string matches with the hash, then the vote is accepted. -If a juror's vote is coherent (more than 51% of other jurors agree) then they receive incentives, otherwise, incentives are deducted from the stake of the juror. - -#### Voting for selection of representatives: -The election is multi-winner approval. We will use seq-phragmen of the substrate to select the representatives. Here, we will keep vote weight as reputation score (instead of stake), the amount of score they obtained through the participation of network. -https://substrate.dev/rustdocs/v3.0.0/sp_npos_elections/fn.seq_phragmen.html -Approval Voting: -Approval Voting -Winners: + +Then jurors will vote for their decision using the commit and reveal scheme. In the commit phase, they submit the hash of the vote string. Then, in the reveal phase, they submit the hash and the vote string. If the vote string matches with the hash, then the vote is accepted. +If a juror's vote is coherent (more than 51% of other jurors agree) then they receive incentives, otherwise, incentives are deducted from the stake of the juror. + +#### Voting for selection of representatives + +The election is multi-winner approval. We will use seq-phragmen of the substrate to select the representatives. Here, we will keep vote weight as reputation score (instead of stake), the amount of score they obtained through the participation of network. + +Approval Voting: +Approval Voting +Winners: Winner -#### Project application and acceptance: -The representatives are in charge of accepting the incoming projects for funding. +#### Project application and acceptance + +The representatives are in charge of accepting the incoming projects for funding. People will submit their problems, for example, waterlogging in the locality. Then experts all around the globe will submit the solution. The solution will be peer-reviewed to check its pros, cons, and suggest improvements that can be made. The review must meet the scientific guidelines. The solution can undergo revision through peer review feedback. -The solution provider and peer reviewer have to stake some money to receive incentives for their work. The solution and peer review will again be approved and disapproved through the shelling game after checking whether the content meets the quality as recommended in scientific guidelines. The solutions provider and reviewer will get the incentives if it gets approved, otherwise, some money will be cut from the stake. It creates pressure on the reviewer to maintain quality without noise. -Problem Solution +The solution provider and peer reviewer have to stake some money to receive incentives for their work. The solution and peer review will again be approved and disapproved through the shelling game after checking whether the content meets the quality as recommended in scientific guidelines. The solutions provider and reviewer will get the incentives if it gets approved, otherwise, some money will be cut from the stake. It creates pressure on the reviewer to maintain quality without noise. +Problem Solution The representatives of the department will select the most optimal solution. -After that persons wanting to take the lead to implement the solution will apply. Again representatives will select the best project leader from the application. +After that persons wanting to take the lead to implement the solution will apply. Again representatives will select the best project leader from the application. -Leadership - +Leadership +### Money for projects -### Money for projects: - -People can either directly donate to the projects or to the department funding pool. Transaction fees of governance token are also collected and kept in the tax funding pool. +People can either directly donate to the projects or to the department funding pool. Transaction fees of governance token are also collected and kept in the tax funding pool. The amount you can contribute to the department funding pool is calculated using the following formula. @@ -89,38 +89,35 @@ Your stake = 100 You can contribute to the funding pool = 50000/10000 * 100 -Then, funding to the projects is distributed through the score schelling game. +Then, funding to the projects is distributed through the score schelling game. + +### Price discovery through Score Schelling Game -### Price discovery through Score Schelling Game: You can rate the project from 1-5, without knowing what others are assigning. If the “mean” of all the product rating is near to your rating then the juror will get incentives, otherwise, juror incentives will be deducted. So, the juror will try to match the score with what others will assign based on information available rather than defecting by any arbitrary rating. We can discover the prices of projects that need to be funded from a common funding pool. Here is an algorithm: + 1) When you submit a project, you need to provide details of the funding needed for work to be done. You can’t provide a funding amount value of more than 4/5 power of the total funding pool amount. e.g. If the total funding pool has $50000, you can’t assign a value larger than $5743 2) Then, we will have a percentage Schelling game to predict the price. That is, you can predict whether to increase or decrease the funding amount in percentage. Remember, it can’t be larger than (Total funding pool amount)^(4/5). Score values will remain from -10 to +10, -10 means 100% decrease, +10 means 100% increase The range of -10 to +10 has a problem because the mean works best without extreme values. So, if someone gives -10, and others give 1, the mean result can get screwed due to the -10 outlier. So the trick is to remove outliers by computing the standard deviation. Remove all values more than one standard deviation away from the mean. Then, we calculate the new mean of the left values (it consists of 68.27% data of the set). Code to calculate new mean: -https://gateway.ipfs.io/ipfs/QmdgL7ytRPSE8vyp5KBffaAjmhGRLusiPcEbt9VWFkgMjf + Score Schelling Game - 3) Then, we will do quality score voting Schelling game that checks the project meets the quality guidelines. The score range is 0-5 4) The amount of funding will be directly proportional to (Predicted Price) * (Quality Score/5*2) Code: -https://gateway.ipfs.io/ipfs/QmcPfQFJKzozLMHFkAesDQc9n2CaEh6M8M4VWdsozgWRB9 + The algorithm tries to meet the values of teal organization through reduced compensation inequality - - - ### Ecosystem Fit +The project will be built on the substrate as a parachain or parathread. -The project will be built on the substrate as a parachain or parathread. - -Other projects similar to it is gitcoin, but its not in Substrate / Polkadot / Kusama ecosystem. Gitcoin uses quadratic funding, but we will use score schelling game for allocation of funds. Gitcoin is for mainly blockchain projects, but our projects includes local community problems. +Other projects similar to it is gitcoin, but its not in Substrate / Polkadot / Kusama ecosystem. Gitcoin uses quadratic funding, but we will use score schelling game for allocation of funds. Gitcoin is for mainly blockchain projects, but our projects includes local community problems. ## Team :busts_in_silhouette: @@ -134,7 +131,7 @@ Other projects similar to it is gitcoin, but its not in Substrate / Polkadot / K * **Contact Name:** Amiya Behera * **Contact Email:** amiyatulu@gmail.com -* **Website:** https://shivarthu.reaudito.com/#/ +* **Website:** ### Legal Structure @@ -143,26 +140,17 @@ Other projects similar to it is gitcoin, but its not in Substrate / Polkadot / K ### Team's experience -Amiya Behera is a full-stack developer and has build many webapps and a few dapps. Has experience in substrate, rust, reactjs, python and also in building mobile apps in react native. +Amiya Behera is a full-stack developer and has build many webapps and a few dapps. Has experience in substrate, rust, reactjs, python and also in building mobile apps in react native. Soumya Ranjan Behera is also a full stack developer with experience in reactjs, react native and python. - - ### Team Code Repos -* https://github.com/amiyatulu -* https://github.com/soumyababu -* https://github.com/amiyatulu/shivarthu - - - - - - +* +* +* ## Development Roadmap :nut_and_bolt: - ### Overview * **Total Estimated Duration:** 8 Months @@ -187,9 +175,6 @@ Soumya Ranjan Behera is also a full stack developer with experience in reactjs, |3.| Reactjs UI for Experience Evaluation| Uploading evidence of experience for the department using IPFS, UI for commit and reveal voting for schelling game and interaction of UI with substrate | |4.| Reactjs Approval Voting UI| Userfriendly UI for voting the representatives where their profile is shown | - - - ### Milestone 2 — Additional features * **Estimated Duration:** 4 month @@ -203,26 +188,22 @@ Soumya Ranjan Behera is also a full stack developer with experience in reactjs, | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 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 our project (what was done/achieved as part of the grant.) | -| 1. | Substrate module: Peer review system | Reviewing the projects using schelling game | -| 2. | Substrate module: Fund allocation | Allocating the fund using score schelling game | +| 1. | Substrate module: Peer review system | Reviewing the projects using schelling game | +| 2. | Substrate module: Fund allocation | Allocating the fund using score schelling game | | 3.| Reactjs UI for peer review system and Fund allocation | User friendly UI for reviewing the projects, schelling game voting interface, and fund allocation | | 4. | Search Engine| Offchain search engine for project discovery and finding representatives | - - - ## Future Plans Short-term: Improve the ideas with discussing with community Increase social media reach Write the source code - + Long-term: Onboard people into the app, and improve it taking feedback from the community. Enhance the app, provide upgrades when required. - ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** Web3 Foundation Website +**How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/Societal.md b/applications/Societal.md index f6ced360f5f..739a0e48b06 100644 --- a/applications/Societal.md +++ b/applications/Societal.md @@ -1,9 +1,8 @@ -# W3F Grant Proposal +# Societal - MVP - Phase 1 -- **Project Name:** Societal - MVP - Phase 1 - **Team Name:** Societal Labs Ltd. - **Payment Address:** Ethereum - USDT: 0xcDcCF94f10d8A7165C1A336DD3795430a6CDE530 -- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview @@ -14,24 +13,25 @@ Societal is an all-in-one Decentralized Autonomous Organization (DAO) creation a Utilizing Polkdaot’s layer-0 infrastructure and ecosystem, Societal will provide DAOs with both maximum functionality and a cohesive user experience. With features including agnostic token compatibility, zero gas fees, a freemium entry point, and a SaaS-based membership pricing, Societal combines best-in-class features into one vertically integrated product. With integrations into DeFi, privacy, and identity protocols, Societal will enable web3 organizations to seamlessly transition and manage their DAOs into the future. -The Societal team has been building in the Polkadot ecosystem for the last year. While at a previous Polkadot project, the Societal team noticed a lack of integrated DAO tooling - not only in the Polkadot ecosystem, but in the broader web3 industry as a whole. After analyzing how we might transition and manage our previous project into a DAO, there was no clear path. This, along with the team being both members and council members of various DAOs and noticing the lack of infrastructure, we decided to build a solution - Societal. +The Societal team has been building in the Polkadot ecosystem for the last year. While at a previous Polkadot project, the Societal team noticed a lack of integrated DAO tooling - not only in the Polkadot ecosystem, but in the broader web3 industry as a whole. After analyzing how we might transition and manage our previous project into a DAO, there was no clear path. This, along with the team being both members and council members of various DAOs and noticing the lack of infrastructure, we decided to build a solution - Societal. ### Project Details -Societal Labs has been designing the product vision of the Socital platform for quite some time. We will go over the project details and blockchain architecture in this application and provide references below for more in-depth context. +Societal Labs has been designing the product vision of the Socital platform for quite some time. We will go over the project details and blockchain architecture in this application and provide references below for more in-depth context. -In Societal's final state, it will offer four main services; Create, Transition, Transfer and Manage. Create will allow any web3 user to create their own DAO. Transition will allow protocols to progressively move towards community ownership. Transfer will allow DAOs to transfer their DAO from an expensive siloed chain to the Sociteal platform. Manage will provide DAOs all the required product features to manage their organization, whether it is a small investment club or a large community-governed protocol. +In Societal's final state, it will offer four main services; Create, Transition, Transfer and Manage. Create will allow any web3 user to create their own DAO. Transition will allow protocols to progressively move towards community ownership. Transfer will allow DAOs to transfer their DAO from an expensive siloed chain to the Sociteal platform. Manage will provide DAOs all the required product features to manage their organization, whether it is a small investment club or a large community-governed protocol. -Societal will offer a wide range of features to create and manage a DAO. The features are split into three categories; Operations, Treasury, and Governance. The Operations features are: job & task boards, payroll, customizable feeds, legal tooling, on-chain reputation, and web & mobile application. The Treasury features are as follows: treasury wallets (multi-sig), DeFi integrations, on-chain cap table, accounting and private asset integrations. The governance features are: zero gas fee governance, proposal calendar, built-in governance models, governance treasury execution, and private voting. +Societal will offer a wide range of features to create and manage a DAO. The features are split into three categories; Operations, Treasury, and Governance. The Operations features are: job & task boards, payroll, customizable feeds, legal tooling, on-chain reputation, and web & mobile application. The Treasury features are as follows: treasury wallets (multi-sig), DeFi integrations, on-chain cap table, accounting and private asset integrations. The governance features are: zero gas fee governance, proposal calendar, built-in governance models, governance treasury execution, and private voting. -Societal will vertically integrate with projects to advance its tech stack and product offering, something not seen in most web3 projects today. For example, Societal can integrate DeFi services by working with projects like Acala, Parallel, and Composable Finance, which will allow for active treasury management for DAOs managed with Societal. For private assets and voting, projects like Manta and Phala can provide privacy-enabling functions like zero-knowledge proofs and trusted execution environments to make this possible. For on-chain credentials, projects like KILT and Litentry can provide KYC and member credentialing services that can be used by DAOs for governance and recruiting. +Societal will vertically integrate with projects to advance its tech stack and product offering, something not seen in most web3 projects today. For example, Societal can integrate DeFi services by working with projects like Acala, Parallel, and Composable Finance, which will allow for active treasury management for DAOs managed with Societal. For private assets and voting, projects like Manta and Phala can provide privacy-enabling functions like zero-knowledge proofs and trusted execution environments to make this possible. For on-chain credentials, projects like KILT and Litentry can provide KYC and member credentialing services that can be used by DAOs for governance and recruiting. The Societal platform will host a vast network of DAOs and eventually offer a Cross-DAO Marketplace. DAO’s onboarded onto the platform will have access to a network of individual DAOs, along with any associated sub-DAOs or guilds. When a DAO has a task that needs to be completed, they will have the ability to post this task to the entire Societal network. This will reach the collective network of sub-DAOs or guilds that may have the ability to complete the required work. The interconnection of DAOs on the Societal platform will open up never before seen opportunities in collaboration across the web3 DAO, sub-DAO, and guild ecosystem. -Finally, Societal plans to progressively transition into a DAO itself. Once the token is launched, a community-run treasury will grow over time until the entire network is owned and operated by the community. +Finally, Societal plans to progressively transition into a DAO itself. Once the token is launched, a community-run treasury will grow over time until the entire network is owned and operated by the community. For more information, please refer to the following resources: + - Societal Whitepaper [here](https://docsend.com/view/2gte2fd8wc4jp4rg) - Societal Docs [here](https://docs.sctl.xyz/) - Societal Testnet Requirements Doc [here](https://docs.google.com/document/d/1seqVIZC-KDVe0ZAdPD1eb8WLKkpirMGB0CcM61eRq3k/edit) @@ -52,11 +52,11 @@ UI Mockups: As it stands today, the DAO landscape within the Polkadot ecosystem is not as mature as other ecosystems such as Ethereum and Solana. This is due to insufficient DAO creation and tooling infrastructure in the ecosystem. Currently, the Polkadot ecosystem does not have the creation, governance, treasury management, and payroll tooling products as other major blockchains. By building these tooling products on Polkadot, both the Polkadot DAO landscape and the broader DAO management tooling space is primed for innovation by utilizing the unique technical abilities that Substrate provides. -The target audience of the Societal application are web3 users who require a platform to easily create and manage their DAO. Using the technical capabilities that Substrate provides, Societal will design our chain to be token agnostic, allowing current MetaMask users to easily connect to our chain and start using the governance application right away. By doing this, our project will meet the needs of the Polkadot community to create their own DAOs and have the tools to manage them as seen in other ecosystems. +The target audience of the Societal application are web3 users who require a platform to easily create and manage their DAO. Using the technical capabilities that Substrate provides, Societal will design our chain to be token agnostic, allowing current MetaMask users to easily connect to our chain and start using the governance application right away. By doing this, our project will meet the needs of the Polkadot community to create their own DAOs and have the tools to manage them as seen in other ecosystems. -The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and DoraFactory. Societal differs from these projects in multiple ways. First, Polkassembly is not building their own parachain and is only a governance platform for large Polkadot projects. Societal wants to allow any web3 user to create their own DAO - not just catering to large established protocols. SubDAO has recently been focusing on smart contract deployments on multiple chains and does not appear to be building a parachain. Societal will build its own parachain and use the technical capabilities of Substrate to be truly token agnostic, connecting with widely used wallets such as MetaMask, to avoid doing multiple chain deployments via smart contracts. Dora Factory is similar to Societal in the sense that they are building their own parachian, however we plan to offer zero gas fees and a SaaS based pricing model to enhance our user's experience. Societal will also seek to integrate with other parachains, having cross-chain smart contract execution. +The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and DoraFactory. Societal differs from these projects in multiple ways. First, Polkassembly is not building their own parachain and is only a governance platform for large Polkadot projects. Societal wants to allow any web3 user to create their own DAO - not just catering to large established protocols. SubDAO has recently been focusing on smart contract deployments on multiple chains and does not appear to be building a parachain. Societal will build its own parachain and use the technical capabilities of Substrate to be truly token agnostic, connecting with widely used wallets such as MetaMask, to avoid doing multiple chain deployments via smart contracts. Dora Factory is similar to Societal in the sense that they are building their own parachian, however we plan to offer zero gas fees and a SaaS based pricing model to enhance our user's experience. Societal will also seek to integrate with other parachains, having cross-chain smart contract execution. -## Team +## Team ### Team members @@ -73,7 +73,7 @@ The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and D ### Legal Structure - **Registered Address:** 707 5 St SW Unit 500, Calgary, AB, Canada T2P 0Y3 -- **Registered Legal Entity:** Societal Labs Ltd. +- **Registered Legal Entity:** Societal Labs Ltd. ### Team's experience @@ -81,16 +81,18 @@ Graeme Fox is the former Director of Business Development at Ruby Protocol, a pr Tyler Gellatly has been building and scaling early stage start-ups for the last 4+ years. He was employee #1 and Director of Operations & Partnerships at Cuboh (a YC-backed SAAS middleware operating within the ghost kitchen industry) More recently, Tyler helped found Ruby Protocol, a novel privacy protocol building on the Substrate framework, and is still involved in a strategic advisory capacity. Currently, he sits on the DAO council for the Illuminati Collective, which currently has a 1000 ETH treasury under management. Tyler holds a Bachelor of Commerce from the University of Victoria, specializing in corporate strategy and finance. A well-rounded business operations leader with a background in finance, operations, capital fundraising, and strategic partnerships, Tyler is mission driven to bring web3 communities together at scale by utilizing blockchain technology. -Max Kudinov is the CEO of Magic Powered, a software development firm building multiple web3 projects. Max has a passion for governance projects and was the Project Lead for the development of [Astro DAO](https://astrodao.com/), an all-in-one DAO creation and management platform built on Near. From this experience, Max has excellent understanding of Rust and how he would like to improve upon the Astro DAO project. Max has highly experienced web3 and rust developers on his team, ready to start the development of this project. +Max Kudinov is the CEO of Magic Powered, a software development firm building multiple web3 projects. Max has a passion for governance projects and was the Project Lead for the development of [Astro DAO](https://astrodao.com/), an all-in-one DAO creation and management platform built on Near. From this experience, Max has excellent understanding of Rust and how he would like to improve upon the Astro DAO project. Max has highly experienced web3 and rust developers on his team, ready to start the development of this project. ### Team Code Repos Org: + - https://github.com/sctllabs Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. Team: + - https://github.com/gfox1 - https://github.com/near-daos - https://github.com/near-daos/astro-ui @@ -117,7 +119,7 @@ Before applying for the Web3 Foundation Grant, the Societal team conducted the f ### Overview - **Total Estimated Duration:** 4 months -- **Full-Time Equivalent (FTE):** 3 FTE +- **Full-Time Equivalent (FTE):** 3 FTE - **Total Costs:** 30,000 USDT @@ -127,7 +129,7 @@ Before applying for the Web3 Foundation Grant, the Societal team conducted the f - **FTE:** 3 - **Costs:** 20,000 USD -The main delivery of this milestone will be the DAO Factory Pallet. This pallet will allow someone to create a DAO on the Societal Network, where the DAO consists of a governance token, treasury and governance system. +The main delivery of this milestone will be the DAO Factory Pallet. This pallet will allow someone to create a DAO on the Societal Network, where the DAO consists of a governance token, treasury and governance system. | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -146,7 +148,7 @@ The main delivery of this milestone will be the DAO Factory Pallet. This pallet - **FTE:** 3 - **Costs:** 10,000 USD -The main delivery of this milestone is to have an easy to use and interactive UI for users to create a DAO and manage its governance and treasury. +The main delivery of this milestone is to have an easy to use and interactive UI for users to create a DAO and manage its governance and treasury. | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -158,19 +160,19 @@ The main delivery of this milestone is to have an easy to use and interactive UI | 1. | Client Modules | We will create a client facing UI that will interact with the Societal chain. The main function of the dashboard will be for the creation of the DAO, and manage its goverance & treasury. | | 2. | Substrate chain | In this milestone the Substrate chain will be built and the necessary pallets will be implemented. The pallets that will be included are: DAO FACTORY, System, Support, Executive, Assets, Authority Discovery, BABE, Balances, Democracy, Elections, Referenda, GRANDPA, Indices, Membership, Multisig, Nicks, Proxy, Scheduler, Transaction Payment, and Treasury | -Notes: Please note that the list of pallets is not exhausted. Some pallets may need to be added or removed from the MVP. However, based on my initial research the pallets listed above will be the required pallets for the Societal chain. +Notes: Please note that the list of pallets is not exhausted. Some pallets may need to be added or removed from the MVP. However, based on my initial research the pallets listed above will be the required pallets for the Societal chain. ## Future Plans -Societal plans to secure fundraising and expand the development team. After the completion of the milestones stated above, Societal plans to expand the product offering by implementing a DAO Market Place and a Mobile App for DAO management. Ideally Societal will be able to secure another Web3 grant for these milestones, along with integrations for [private voting](https://github.com/w3f/Grants-Program/blob/master/rfps/anti-collusion%20infrastructure.md) and [identity voting](https://github.com/w3f/Grants-Program/blob/master/rfps/identity-directory.md) based on links to the RFPs. From there, Societal would also like to apply for the Substrate Builders Program, establishing itself at the go to DAO and governance platform. Finally, Societal will progressively transition into a DAO itself and release control to the community. +Societal plans to secure fundraising and expand the development team. After the completion of the milestones stated above, Societal plans to expand the product offering by implementing a DAO Market Place and a Mobile App for DAO management. Ideally Societal will be able to secure another Web3 grant for these milestones, along with integrations for [private voting](https://github.com/w3f/Grants-Program/blob/master/rfps/anti-collusion%20infrastructure.md) and [identity voting](https://github.com/w3f/Grants-Program/blob/master/rfps/identity-directory.md) based on links to the RFPs. From there, Societal would also like to apply for the Substrate Builders Program, establishing itself at the go to DAO and governance platform. Finally, Societal will progressively transition into a DAO itself and release control to the community. ## Additional Information -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** Societal heard about the Grants Program from our time building in the Polkadot Ecosystem. @@ -183,4 +185,4 @@ Additional Information: - Yes, all the founders of Societal Labs have contributed financially to the project. - Previous grants you may have applied for? - - No other grants have been applied for. + - No other grants have been applied for. diff --git a/applications/SpiderDAO.md b/applications/SpiderDAO.md index 3cf94fbb377..028a1ab0ba5 100644 --- a/applications/SpiderDAO.md +++ b/applications/SpiderDAO.md @@ -1,16 +1,18 @@ # SpiderDAO Grant Proposal + ![](https://i.imgur.com/zlw9lZ3.png) -* **Project:** SpiderDAO -* **Proposer:** [SpiderDAO] (https://github.com/SpiderDAO) + +* **Proposer:** [SpiderDAO] () * **Payment Address:** 3Pxq3ViqRW6b3e7qsX7Mo7gSikHcToa7ig * **Document Version:** Version 2.4 * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/129#issuecomment-1011987896) +## Project Overview :page_facing_up: -## Project Overview :page_facing_up: **SpiderDAO** is a next-generation hardware-based DAO governance model that aims to bring a new standard of fairness to existing DAO frameworks. Traditional DAO models are subject to attack and takeover by plutocracies controlled by wealthy whales. He who controls the votes controls the DAO. ### Overview + **SpiderDAO** is a unique governance infrastructure layer for a hardware-enabled DAO and can be applied in a variety of use cases. As the first use case, Spider will leverage its well-established presence in the hardware VPN market together with a partnership with Sentinel, an established dVPN provider and BPSAA Alliance member, to create a fully self-governing decentralized VPN network called SpiderVPN. We intend for SpiderDAO to run on its own Parachain on the Polkadot network. If the bond cannot be funded, the protocol will run on Parathreads or possibly as a series of smart contracts. Our initial testnet and protocol configuration will be built on Kusama and ported onto Polkadot for the mainnet launch. @@ -18,6 +20,7 @@ We intend for SpiderDAO to run on its own Parachain on the Polkadot network. If We believe that in order to fulfil the SpiderDAO’s vision of bringing greater privacy to the end-user, it is vital to establish a robust ecosystem that prioritises users’ interests. To do this, we must first establish a resilient, scalable and community-led governance system that dynamically adapts to the rapidly changing times. We believe that building a decentralised autonomous organisation is the perfect mechanism that will enable us to reach this goal. ### Project Details + ![](https://i.imgur.com/4y8BwFo.png) SpiderDAO’s long term vision is to propose a set of tools bringing privacy and security to today and tomorrow's internet users. To do so in an efficient and sustainable fashion, SpiderDAO’s team imagined and leveraged a robust DAO standard that will withstand the incredible adversity that such a mission implies. A first step is to address the plutocracy governance problem in traditional DAOs by introducing a set of rules that must be abided by to qualify for the right to an on-chain vote via the DAO. @@ -28,12 +31,12 @@ The SpiderConnect Hardware Router can be purchased by any community member, once ![](https://i.imgur.com/XFm46ql.png) - -**SpiderDAO** ecosystem brings together several other components to provide the building blocks for growing and sustaining a dynamic ecosystem. +**SpiderDAO** ecosystem brings together several other components to provide the building blocks for growing and sustaining a dynamic ecosystem. ![](https://i.imgur.com/AGJhoA5.png) **Spider Ecosystem will include:** + * SpiderDAO is the first hardware-governed DAO with a self-maintaining and self-improving robust Hardware/Software Governance control mechanism. * SpiderConnect Routers offer multiple roles as a high-speed VPN tunnel, a DAO voting ticket, and a node in a fully autonomous decentralised VPN. * SpiderVPN is a Virtual Private Network interlinking all the elements of the DAO & offering a complimentary dVPN service for qualifying users. @@ -43,71 +46,68 @@ The SpiderConnect Hardware Router can be purchased by any community member, once * **SpiderDashboard** (as seen Below) will provide an end-users access point to the features of the SpiderDAO. ![](https://i.imgur.com/UuanKdg.png) - - + ### Ecosystem Fit We see many projects in the Polkadot ecosystem that are having similar issues when it comes to voting system: MANTRA DAO is one of the examples. -The main problem with **Mantra DAO** which is built on **Rio Chain** is the same problem that many other DAOs faces where each token represent 1 vote in the ecosystem which introduces a major problem with the governing body where whales can take control of the DAO by buying big amounts of tokens making them in a way the deciding vote for any proposals. +The main problem with **Mantra DAO** which is built on **Rio Chain** is the same problem that many other DAOs faces where each token represent 1 vote in the ecosystem which introduces a major problem with the governing body where whales can take control of the DAO by buying big amounts of tokens making them in a way the deciding vote for any proposals. -### To solve this we intend to add the following features. +### To solve this we intend to add the following features **SpiderConnect Router Security** -- Our routers do have a secured ROM which we can control securely for all units and that's where the essential data will be saved. Our unique ID which currently contains the mac address & the router serial number will be combined with the wallet address and encrypted using our algorithm to make sure it would be nearly impossible to be compromised. +* Our routers do have a secured ROM which we can control securely for all units and that's where the essential data will be saved. Our unique ID which currently contains the mac address & the router serial number will be combined with the wallet address and encrypted using our algorithm to make sure it would be nearly impossible to be compromised. **Whale Resistant Voting Model** -- Our model shifts voting power away from token holders to hardware owners, where one validated router equals one vote. Additionally, Blockchain-based router tracking ensures that hoarding of devices are instantaneously detected by the network and ‘fake’ routers are locked out of the network. The liquidity incentive mechanism will be available to all users and not just people with routers so the entry barrier is removed in this case. +* Our model shifts voting power away from token holders to hardware owners, where one validated router equals one vote. Additionally, Blockchain-based router tracking ensures that hoarding of devices are instantaneously detected by the network and ‘fake’ routers are locked out of the network. The liquidity incentive mechanism will be available to all users and not just people with routers so the entry barrier is removed in this case. **Voting by Direct Democracy** -- Our voting mechanism would be classified as a Direct Democracy system. We are going to balance the voting power by only allowing token holders to have one router regardless of how many tokens they hold. We will make sure they got to go through SpiderConnect to gain more routers for their tokens if we agreed to that. Our DPI filters will monitor that keeping their identity anonymous. +* Our voting mechanism would be classified as a Direct Democracy system. We are going to balance the voting power by only allowing token holders to have one router regardless of how many tokens they hold. We will make sure they got to go through SpiderConnect to gain more routers for their tokens if we agreed to that. Our DPI filters will monitor that keeping their identity anonymous. + + **How will spiderDAO try and prevent Whales/Bots from manipulating the Hardware Governnace?** - **How will spiderDAO try and prevent Whales/Bots from manipulating the Hardware Governnace?** - -- We are aware that whales/bots can buy more routers using new wallets to try and affect the governance model, but that will come at a heavy cost for adding more routers and also have to wait for a period of time deemed reasonable to the DAO. Users must have active transactions on the wallet before being able to vote to make sure bots and whales won't get access with ease. +* We are aware that whales/bots can buy more routers using new wallets to try and affect the governance model, but that will come at a heavy cost for adding more routers and also have to wait for a period of time deemed reasonable to the DAO. Users must have active transactions on the wallet before being able to vote to make sure bots and whales won't get access with ease. -- We will be keeping a log of every MAC Address and serial number for every router we add to our inventory, this we’ll be added to an on-chain ledger or on-chain database. This will help us to identify any clone or anyone trying to spoof/manipulate the hardware. +* We will be keeping a log of every MAC Address and serial number for every router we add to our inventory, this we’ll be added to an on-chain ledger or on-chain database. This will help us to identify any clone or anyone trying to spoof/manipulate the hardware. We will also be in constant contact with the growing SpiderDAO community and the open-source community for beneficial ideas on how to make the governorate safer and more resilient to whales-resistance. -- If the essential data (explained below) is not matched to the end-user and they try to spoof or manipulate access. There will be 3 warnings followed by a ban from taking a part in our governance model for a limited time(still to be decided). The ban time will be increased systematically based on the number of times this is identified until the customer is banned indefinitely if the infringement persistently continues. - +* If the essential data (explained below) is not matched to the end-user and they try to spoof or manipulate access. There will be 3 warnings followed by a ban from taking a part in our governance model for a limited time(still to be decided). The ban time will be increased systematically based on the number of times this is identified until the customer is banned indefinitely if the infringement persistently continues. + **What is the essential data?** **The essential data is a combination of the following:** -- Encrypted wallet seed using aes-256-cbc encryption standard with an auto-generated passphrase* saved as part of the essential data. -- Router Mac Address to avoid it being cloned. -- Router serial number which cannot be cloned as it's a part of the chipset code. -- SHA-512 checksum for a temp file that is created with all the data above which is updated every time the router is rebooted with the timestamp. +* Encrypted wallet seed using aes-256-cbc encryption standard with an auto-generated passphrase* saved as part of the essential data. +* Router Mac Address to avoid it being cloned. +* Router serial number which cannot be cloned as it's a part of the chipset code. +* SHA-512 checksum for a temp file that is created with all the data above which is updated every time the router is rebooted with the timestamp. **PS:** Please note the passphrase would only be local and will be independent to the requests sent by the router for the governorate operations. **Is SpiderConnect Hardware Router open-source?** - -- Yes as we want to be involved much more in the open-source community, We are going to be using the Uboot environment with its open-source code to save the essential data which would be listed in the next question. -- To go into more detail on that point, We will also be giving our community members the option to choose between Open Source wireless drivers and the closed source ones for them to choose so we can make sure we offer an OpenSource friendly solution. +* Yes as we want to be involved much more in the open-source community, We are going to be using the Uboot environment with its open-source code to save the essential data which would be listed in the next question. + +* To go into more detail on that point, We will also be giving our community members the option to choose between Open Source wireless drivers and the closed source ones for them to choose so we can make sure we offer an OpenSource friendly solution. **PS:** No secured or closed source ROM will be needed using this solution - - **How we plan to build on Polkadot Ecosystem?** - -- We are planning to build using smart contracts at the beginning but as we scale up to more transactions, We are most likely to move toward a shared solution so we can cut the costs and take charge of how our blockchain will operate. -**How we plan to achieve on-chain and off-chain communication with SpiderConnect Routers and SpiderDAO governance?** + **How we plan to build on Polkadot Ecosystem?** -- We are planning to write a substrate faucet to communicate with our discord server for our customers to send the token needed for the vote, Initiate voting, pass on the vote for the voting process that would be operated through our discord server. -- Real votes will be done through our substrate faucet until the final Polkadot/SpiderDAO flavour features are fully-fledged. - +* We are planning to build using smart contracts at the beginning but as we scale up to more transactions, We are most likely to move toward a shared solution so we can cut the costs and take charge of how our blockchain will operate. +**How we plan to achieve on-chain and off-chain communication with SpiderConnect Routers and SpiderDAO governance?** +* We are planning to write a substrate faucet to communicate with our discord server for our customers to send the token needed for the vote, Initiate voting, pass on the vote for the voting process that would be operated through our discord server. +* Real votes will be done through our substrate faucet until the final Polkadot/SpiderDAO flavour features are fully-fledged. ## Team :busts_in_silhouette: ### Team members + * Nathan Varty (Full-Time, Founder, CEO) * Žiga Flis (Full-Time, Founder, Senior blockchain Developer & Analyst) * Anas Sayed (Full-Time, Founder, CTO, Development Manager, Architecture, Full Network Stack Implementation) @@ -116,40 +116,49 @@ We will also be in constant contact with the growing SpiderDAO community and the * Pierre Laurent (Strategic Advisor, Blockchain and crypto Enthusiast) ### Team Website -* https://spiderdao.io + +* ### Legal Structure + **SpiderDAO** is incorporated in Cayman Island. ### Team's experience + **Nathan Varty** + * Experienced entrepreneur specialized in IoT development and operations, Skilled in management of onsite Developers. * Successfully overseeing SpiderVPN's operations since 2017. * Passionate about decentralizing global currency and governance with the vision to implement that in wider fields. * Over 5 years experience investing and trading in digital assets. **Žiga Flis** + * Worked as a Chief Technology Officer at RiveX, where he contributed to the development of various blockchain technologies. * Experienced in on and off-chain tech and has a passion for developing decentralized solutions. * Experienced in crypto markets since 2016. **Anas Sayed** + * Long standing Project Manager and working with teams of Developers and Administrators. * Worked on many projects in Entertainment/Telecommunications field including FuboTV, Pensil Media, SpiderVPN. * Currently working on different projects with market leaders in Telecommunications field. * Bachelor’s Degree in Computer Science from HICIT in Shorouk Academy, Egypt. **Alexy Petrunin** + * Experienced backend developers with full SDLC implementations. * Developed multiple OpenWRT projects. * Extensive knowledge in all Open Systems Interconnection (OSI) model. **Dr. Alfie Zhao** + * Chief Technology Officer, GL Technologies (Hong Kong) Limited. * Winner of CES innovation awards in 2019 and 2020. * PhD in engineering management with proven track record in hardware IoT since 2012. **Pierre Laurent** + * Co-founder at Atka advisory. * Overseeing the European operation of a cryptocurrency exchange as Blockchain Partnerships Manager in 2018 * Early adopter of Blockchain and advisor on several projects @@ -157,22 +166,24 @@ We will also be in constant contact with the growing SpiderDAO community and the * Tech-savvy, startup enthusiast, passionate about blockchain technologies. ### Team Code Repos -* https://github.com/spiderdao -* https://github.com/painfull30 -* https://github.com/flisko + +* +* +* ### Team LinkedIn Profiles -* **Nathan Varty** https://www.linkedin.com/in/nathan-varty-b07235162/ -* **Žiga Flis** https://www.linkedin.com/in/%C5%BEiga-flis-3112896b/ -* **Anas Sayed** https://www.linkedin.com/in/anas-sayed-34a99b73/ -* **Alexy Petrunin** https://www.linkedin.com/in/alexey-petrunin-aa06807a/ -* **Dr. Alfie Zhao** https://www.linkedin.com/in/jianbin-zhao-2b04567/ -* **Pierre Laurent** https://www.linkedin.com/in/pierrelaurent789/ +* **Nathan Varty** +* **Žiga Flis** +* **Anas Sayed** +* **Alexy Petrunin** +* **Dr. Alfie Zhao** +* **Pierre Laurent** -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: ### Overview + * **Total Estimated Duration:** 2 Months/POC * **Full-time equivalent (FTE):** 15.57 * **Total Costs:** 1.67 BTC @@ -183,37 +194,43 @@ We will also be in constant contact with the growing SpiderDAO community and the | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a full tutorial that explains how to interact and communicate with the testnet protocol | -| 0c. | Testing Guide | The code will have proper unit-test coverage (>90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | +| 0c. | Testing Guide | The code will have proper unit-test coverage (>90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | | 1. | Testing | We will conduct testing of the developed functionalities on Westend testnet. | | 2. | DAO framework | We are going to build our DAO framework using Ink! Smart Contracts for this milestone. | | 3. | Discord Communication | Write a substrate faucet to establish communication between SpiderConnect Hardware Router & discord server allowing contribution to SpiderDAO by allowing users to send the token needed for the vote, Initiate voting, pass on the vote for the voting process that would be operated through our discord server. | -| 4. | Build TestNet | The testnet will be based on Substrate framework for this milestone. | -| 5. | Test SpiderDAO | Successfully connect DAO entities (individual voters) to Spider routers. This will include one use case to show the connection is established correctly using Discord communications. We will be using Python with the help of https://github.com/polkascan/py-substrate-interface library. | +| 4. | Build TestNet | The testnet will be based on Substrate framework for this milestone. | +| 5. | Test SpiderDAO | Successfully connect DAO entities (individual voters) to Spider routers. This will include one use case to show the connection is established correctly using Discord communications. We will be using Python with the help of library. | | 6. | Medium Article | Create a medium article to announce all deliveries to the community once passed evaluation. | | 7. | Repository | Repository including a README that describes the milestone and explains how to run, test and contribute | | 8. | Docker | A docker container that will also run on CI to test the deliverables of the milestone | ### Community engagement + We plan to write several pieces about SpiderDAO/SpiderVPN implementation. They include, but are not limited to: + * Weekly Medium Articles * Daily Twitter Threads and Posts * We also intend to engage community by running range of incentivised testnets to get more feedback from the existing end-users to improve our product. * Educating an Ideal processes of hardware voting policy in a DAO structure ## Future Plans + Future Developments will focus on the following: + * Incentive programs for validators * Bug bounties * Hackathon * Grants to develop new products under the SpiderDAO Umbrella -* Decentralized SpiderChat | SpiderCloud | SpiderMail +* Decentralized SpiderChat | SpiderCloud | SpiderMail **Open Source Development Opportunities** -* Hardware DAO Development + +* Hardware DAO Development * Networking Routers * Operating Systems -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: + Any additional information that you think is relevant to this application that hasn't already been included. * **What work has been done so far?** diff --git a/applications/Standard_Protocol.md b/applications/Standard_Protocol.md index 6ee0688ed9a..cd3df35019a 100644 --- a/applications/Standard_Protocol.md +++ b/applications/Standard_Protocol.md @@ -1,7 +1,6 @@ # Standard Protocol - -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview @@ -10,12 +9,15 @@ Standard Protocol is a collaterized algorithmic stablecoin protocol for syntheti ### Problems of current algorithmic stablecoins #### 1. Too much focus on price stability, no sustainable use case for interoperability + Current algorithmic stablecoins focus only on automated price stability. Although they provide some interoperability between tokens with initial distribution in yield farming, but currently there is no sustainable way for them to interoperate with financial activities without the reward. Also, other algorithmic stablecoins which uses incentives in cases regarding circulating supply(e.g. contractionary, expansionary cases) are not showing sustainability to preserve 1 dollar peg. -#### 2. Oracles are centralized, and there is no decentralized ecosystem to reward them +#### 2. Oracles are centralized, and there is no decentralized ecosystem to reward them + One can be dependant to dexes, but they are prone to flash loans, making arbitrage data compared to centralized exchange. In order to provide aggregated and balanced data, oracle providers must be rewarded. -#### 3. Auctions are hard to track and centralized +#### 3. Auctions are hard to track and centralized + Auctions after liquidation are hard to track and participate, leaving only hardcore traders to take advantage of arbitrage. More decentralized way to provide liquidation must be considered. Auction orders come in high volume of collateral, and this can lead to plutocracy. ### Solutions @@ -40,7 +42,7 @@ Instead of hosting an auction for liquidating collaterals, Standard protocol dep #### token regisrty `/token` -Token manages asset that flows in and out with xcmp in polkadot ecosystem. assets are managed with unique identifier. +Token manages asset that flows in and out with xcmp in polkadot ecosystem. assets are managed with unique identifier. #### oracle reward module `/oracle` @@ -53,9 +55,9 @@ Market module in standard protocol manages pair for automated market maker(AMM) #### vault module `/vault` -Vault module in standard protocol is a collateral debt position engine where +Vault module in standard protocol is a collateral debt position engine where -### Ecosystem Fit +### Ecosystem Fit Standard protocol will act as the catalyst for other parachain's financial activities for enabling leverage trading and Arbitrage in AMM created from liquidation. It will also open a protocol for synthetic asset market with decentralized oracle ecosystem. @@ -66,19 +68,22 @@ Standard protocol will act as the catalyst for other parachain's financial activ Hyungsuk Kang, team leader ### Legal Structure + Standard protocol is being made with Apache 2.0 license. Legal entity is being built in Singapore right now. ### Team's experience -Hyungsuk is Plasm network's core developer. He developed Subswap, AMM in substrate, and he wants to extend it to make the next finance in Polkadot ecosytem using XCM module and collateral debt position. He is also kernel and tendermint fellow. + +Hyungsuk is Plasm network's core developer. He developed Subswap, AMM in substrate, and he wants to extend it to make the next finance in Polkadot ecosytem using XCM module and collateral debt position. He is also kernel and tendermint fellow. ### Team Code Repos -* https://github.com/digitalnativeinc/standard-substrate +* ### Team LinkedIn Profiles -* https://www.linkedin.com/in/hyungsukkang -## Development Roadmap :nut_and_bolt: +* + +## Development Roadmap :nut_and_bolt: ### Overview @@ -92,6 +97,7 @@ To reward the network participant, Standard protocol proposes new PoS reward sys * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/244#issuecomment-1014764739) ### Milestone 1 - Middleware for data submission and runtime integration + * **Estimated Duration:** 1 month * **FTE:** 1 * **Costs:** 500DAI @@ -100,7 +106,7 @@ This milestone focuses on building a oracle provider client middleware which sub ### Oracle provider client -As chainlink and other oracle solution has a middleware or submitting client from off-chain, Standard also has its oracle client. Oracle provider client is actually a bot that uses [polkadot-js api](https://github.com/scs/substrate-api-client/blob/master/tutorials/api-client-tutorial/src/main.rs) to submit information in oracle module in a certain periods(e.g. 2 hour, 4 hour). For example, to send an oracle xt from an oracle client, +As chainlink and other oracle solution has a middleware or submitting client from off-chain, Standard also has its oracle client. Oracle provider client is actually a bot that uses [polkadot-js api](https://github.com/scs/substrate-api-client/blob/master/tutorials/api-client-tutorial/src/main.rs) to submit information in oracle module in a certain periods(e.g. 2 hour, 4 hour). For example, to send an oracle xt from an oracle client, ```javascript= // Loads config @@ -149,32 +155,29 @@ Here is the overall workflow for the client operation, and add-ons and options a ## Unit tests -Standard protocol applies test driven development(TDD) on building runtime modules for the grant. +Standard protocol applies test driven development(TDD) on building runtime modules for the grant. Here are unit tests that will be done along the development in the runtime module. ## Oracle oracle in milestone 1 should achieve: -- Only Root account can register oracle providers for slots to submit off-chain data -- If slots are not open for an entity in the storage, a new oracle provider initializes the slot with the oracle provider count. -- When the provider is designated for a slot, it can only submit data for a designated slot -- If one reports slashing for the slot, runtime validates the slot data with iqr rule and remove provider and set the value as zero if the value violates it. -- zero values are excluded and the median is calculated in both even and odd cases +* Only Root account can register oracle providers for slots to submit off-chain data +* If slots are not open for an entity in the storage, a new oracle provider initializes the slot with the oracle provider count. +* When the provider is designated for a slot, it can only submit data for a designated slot +* If one reports slashing for the slot, runtime validates the slot data with iqr rule and remove provider and set the value as zero if the value violates it. +* zero values are excluded and the median is calculated in both even and odd cases To check this, oracle provider module should have these test functions: -- `add_oracle_provider_works`: Oracle should be added by the root account for now until the module includes session callback between `pallet-staking` and `pallet-session` as a impl of `SessionManager`. -- `oracle_report_works`: Oracle provider should only be able to submit data only in designated slot, and create new batch if the price data has not been reported yet. -- `oracle_slash_works`: when one reports slashing for oracle provider in a slot, the runtime should run iqr rule to find out whether the slot value violates the rule from the collected oracle data batch. -- `oracle_excludes_zeros_and_return_median`: Oracle runtime should exclude zero-values since it means the data is empty or not available due to violation. median should be returned from the remainder of filtered batch. -- `oracle_excludes_zeros_and_return_median_even`: the purpose is also same with the previous test function, but the batch length is even. - - - +* `add_oracle_provider_works`: Oracle should be added by the root account for now until the module includes session callback between `pallet-staking` and `pallet-session` as a impl of `SessionManager`. +* `oracle_report_works`: Oracle provider should only be able to submit data only in designated slot, and create new batch if the price data has not been reported yet. +* `oracle_slash_works`: when one reports slashing for oracle provider in a slot, the runtime should run iqr rule to find out whether the slot value violates the rule from the collected oracle data batch. +* `oracle_excludes_zeros_and_return_median`: Oracle runtime should exclude zero-values since it means the data is empty or not available due to violation. median should be returned from the remainder of filtered batch. +* `oracle_excludes_zeros_and_return_median_even`: the purpose is also same with the previous test function, but the batch length is even. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0| -| 0b. | Documentation | Documentation will introduce how to install the oracle and participate to get block reward | +| 0b. | Documentation | Documentation will introduce how to install the oracle and participate to get block reward | | 1. | Oracle client | Oracle client to receive information from external sources then submit information regularly to substrate runtime | | 2. | Modified Oracle module | Oracle module to register operators and batch | | 3. | Unit test codes | Unit test codes in `tests.rs` in each runtime module | @@ -182,13 +185,14 @@ To check this, oracle provider module should have these test functions: | 5. | Dockerfile | Dockerfile for running Standard protocol binary will be provided | ### Milestone 2 - PoS oracle reward distribution + * **Estimated Duration:** 1 month * **FTE:** 1 * **Costs:** 500DAI -This milestone focuses on including session callbacks related to sessions in implementations of `SessionManager` trait in `pallet-staking` module, and all related module will be tested with its separate implementation of `SessionManager` connected to `pallet-session` in a mock environment. +This milestone focuses on including session callbacks related to sessions in implementations of `SessionManager` trait in `pallet-staking` module, and all related module will be tested with its separate implementation of `SessionManager` connected to `pallet-session` in a mock environment. -## Vault +## Vault Vault in milestone 2 should have a trait for dependency Injection: @@ -217,209 +221,204 @@ where the it will be included in `pallet-staking` module's `SessionManager` trai /// Once the first new_session is planned, all session must start and then end in order, though /// some session can lag in between the newest session planned and the latest session started. impl pallet_session::SessionManager for Module { - fn new_session(new_index: SessionIndex) -> Option> { - frame_support::debug::native::trace!( - target: LOG_TARGET, - "[{}] planning new_session({})", - >::block_number(), - new_index - ); - Self::new_session(new_index) - } - fn start_session(start_index: SessionIndex) { - frame_support::debug::native::trace!( - target: LOG_TARGET, - "[{}] starting start_session({})", - >::block_number(), - start_index - ); - Self::start_session(start_index) - } - fn end_session(end_index: SessionIndex) { - frame_support::debug::native::trace!( - target: LOG_TARGET, - "[{}] ending end_session({}) with rebase", - >::block_number(), - end_index - ); + fn new_session(new_index: SessionIndex) -> Option> { + frame_support::debug::native::trace!( + target: LOG_TARGET, + "[{}] planning new_session({})", + >::block_number(), + new_index + ); + Self::new_session(new_index) + } + fn start_session(start_index: SessionIndex) { + frame_support::debug::native::trace!( + target: LOG_TARGET, + "[{}] starting start_session({})", + >::block_number(), + start_index + ); + Self::start_session(start_index) + } + fn end_session(end_index: SessionIndex) { + frame_support::debug::native::trace!( + target: LOG_TARGET, + "[{}] ending end_session({}) with rebase", + >::block_number(), + end_index + ); T::Rebase::rebase(); - Self::end_session(end_index) - } + Self::end_session(end_index) + } } ``` - vault in milestone 2 should achieve: -- In each era, vault module should bring registered stablecoin price from oracle module with its asset id (1) and rebase its total supply to `(circulating supply) / (oracle price)` in order to satisfy the ratio `(circulating supply) : (oracle price) = (total supply) : (1.0(USD) in decimal configured in the substrate chain)`. -- Vault module should burn or mint stablecoin's module account's balance according to rebased balance -- Alert community when total supply cannot be decreased anymore to keep the ratio(in case where decreased total supply exceeds circulating supply) in order to propose emergency shutdown or take further actions(e.g. issuing bonds, using community vault from stability fee to stabilize the ratio) +* In each era, vault module should bring registered stablecoin price from oracle module with its asset id (1) and rebase its total supply to `(circulating supply) / (oracle price)` in order to satisfy the ratio `(circulating supply) : (oracle price) = (total supply) : (1.0(USD) in decimal configured in the substrate chain)`. +* Vault module should burn or mint stablecoin's module account's balance according to rebased balance +* Alert community when total supply cannot be decreased anymore to keep the ratio(in case where decreased total supply exceeds circulating supply) in order to propose emergency shutdown or take further actions(e.g. issuing bonds, using community vault from stability fee to stabilize the ratio) To check this, vault module should have these test functions: -- `supply_is_rebased_in_each_era`: Using an oracle module, set an oracle price and start an era so that the vault module can executes rebase mechanism. The total supply of the stablecoin is checked whether it changed to the right amount. -- `report_emergency`: check whether vault module reports when the rebased next total supply is less than the circulating supply. - +* `supply_is_rebased_in_each_era`: Using an oracle module, set an oracle price and start an era so that the vault module can executes rebase mechanism. The total supply of the stablecoin is checked whether it changed to the right amount. +* `report_emergency`: check whether vault module reports when the rebased next total supply is less than the circulating supply. ## Oracle oracle will replicate the `pallet-staking` module regarding election of the oracle provider and the reward logic. However, there will be difference in how the elected provider(or validator) is allocated to the slot. The module only accepts the stash account to submit oracle data once `validate()` tx has been finalized. -For example, there will be addition in the `select_and_update_validators` function code +For example, there will be addition in the `select_and_update_validators` function code ```rust= /// Select the new validator set at the end of the era. - /// - /// Runs [`try_do_phragmen`] and updates the following storage items: - /// - [`EraElectionStatus`]: with `None`. - /// - [`ErasStakers`]: with the new staker set. - /// - [`ErasStakersClipped`]. - /// - [`ErasValidatorPrefs`]. - /// - [`ErasTotalStake`]: with the new total stake. - /// - [`SnapshotValidators`] and [`SnapshotNominators`] are both removed. - /// - /// Internally, [`QueuedElected`], snapshots and [`QueuedScore`] are also consumed. - /// - /// If the election has been successful, It passes the new set upwards. - /// - /// This should only be called at the end of an era. - fn select_and_update_validators(current_era: EraIndex) -> Option> { - if let Some(ElectionResult::> { - elected_stashes, - exposures, - compute, - }) = Self::try_do_election() { - // Totally close the election round and data. - Self::close_election_window(); - - // Populate Stakers and write slot stake. - let mut total_stake: BalanceOf = Zero::zero(); - exposures.into_iter().for_each(|(stash, exposure)| { - total_stake = total_stake.saturating_add(exposure.total); - >::insert(current_era, &stash, &exposure); - - let mut exposure_clipped = exposure; - let clipped_max_len = T::MaxNominatorRewardedPerValidator::get() as usize; - if exposure_clipped.others.len() > clipped_max_len { - exposure_clipped.others.sort_by(|a, b| a.value.cmp(&b.value).reverse()); - exposure_clipped.others.truncate(clipped_max_len); - } - >::insert(¤t_era, &stash, exposure_clipped); - }); - - // Insert current era staking information - >::insert(¤t_era, total_stake); - - // collect the pref of all winners - for (i, stash) in elected_stashes.iter().enumerate() { + /// + /// Runs [`try_do_phragmen`] and updates the following storage items: + /// - [`EraElectionStatus`]: with `None`. + /// - [`ErasStakers`]: with the new staker set. + /// - [`ErasStakersClipped`]. + /// - [`ErasValidatorPrefs`]. + /// - [`ErasTotalStake`]: with the new total stake. + /// - [`SnapshotValidators`] and [`SnapshotNominators`] are both removed. + /// + /// Internally, [`QueuedElected`], snapshots and [`QueuedScore`] are also consumed. + /// + /// If the election has been successful, It passes the new set upwards. + /// + /// This should only be called at the end of an era. + fn select_and_update_validators(current_era: EraIndex) -> Option> { + if let Some(ElectionResult::> { + elected_stashes, + exposures, + compute, + }) = Self::try_do_election() { + // Totally close the election round and data. + Self::close_election_window(); + + // Populate Stakers and write slot stake. + let mut total_stake: BalanceOf = Zero::zero(); + exposures.into_iter().for_each(|(stash, exposure)| { + total_stake = total_stake.saturating_add(exposure.total); + >::insert(current_era, &stash, &exposure); + + let mut exposure_clipped = exposure; + let clipped_max_len = T::MaxNominatorRewardedPerValidator::get() as usize; + if exposure_clipped.others.len() > clipped_max_len { + exposure_clipped.others.sort_by(|a, b| a.value.cmp(&b.value).reverse()); + exposure_clipped.others.truncate(clipped_max_len); + } + >::insert(¤t_era, &stash, exposure_clipped); + }); + + // Insert current era staking information + >::insert(¤t_era, total_stake); + + // collect the pref of all winners + for (i, stash) in elected_stashes.iter().enumerate() { >::insert(i, stash.clone()); // allocating slots for elected oracle provider - let pref = Self::validators(stash); - >::insert(¤t_era, stash, pref); - } + let pref = Self::validators(stash); + >::insert(¤t_era, stash, pref); + } - // emit event - Self::deposit_event(RawEvent::StakingElection(compute)); - - log!( - info, - "💸 new validator set of size {:?} has been elected via {:?} for era {:?}", - elected_stashes.len(), - compute, - current_era, - ); - - Some(elected_stashes) - } else { - None - } - } + // emit event + Self::deposit_event(RawEvent::StakingElection(compute)); + + log!( + info, + "💸 new validator set of size {:?} has been elected via {:?} for era {:?}", + elected_stashes.len(), + compute, + current_era, + ); + + Some(elected_stashes) + } else { + None + } + } ``` Also, slash module function should include verifier from milestone 1. ```rust= /// Slash the validator for a given amount of balance. This can grow the value - /// of the slash in the case that the validator has less than `minimum_balance` - /// active funds. Returns the amount of funds actually slashed. - /// - /// Slashes from `active` funds first, and then `unlocking`, starting with the - /// chunks that are closest to unlocking. - fn slash( - &mut self, - mut value: Balance, - minimum_balance: Balance, + /// of the slash in the case that the validator has less than `minimum_balance` + /// active funds. Returns the amount of funds actually slashed. + /// + /// Slashes from `active` funds first, and then `unlocking`, starting with the + /// chunks that are closest to unlocking. + fn slash( + &mut self, + mut value: Balance, + minimum_balance: Balance, slot: SlotIndex, - ) -> Balance { - let batch = Prices::get(_id).unwrap(); - let value = batch[_slot as usize]; - let det = Self::determine_outlier(batch, value); - ensure!(det, Error::::NotOutlier); - let pre_total = self.total; - let total = &mut self.total; - let active = &mut self.active; - - let slash_out_of = | - total_remaining: &mut Balance, - target: &mut Balance, - value: &mut Balance, - | { - let mut slash_from_target = (*value).min(*target); - - if !slash_from_target.is_zero() { - *target -= slash_from_target; - - // don't leave a dust balance in the staking system. - if *target <= minimum_balance { - slash_from_target += *target; - *value += sp_std::mem::replace(target, Zero::zero()); - } - - *total_remaining = total_remaining.saturating_sub(slash_from_target); - *value -= slash_from_target; - } - }; - - slash_out_of(total, active, &mut value); - - let i = self.unlocking.iter_mut() - .map(|chunk| { - slash_out_of(total, &mut chunk.value, &mut value); - chunk.value - }) - .take_while(|value| value.is_zero()) // take all fully-consumed chunks out. - .count(); - - // kill all drained chunks. - let _ = self.unlocking.drain(..i); - - pre_total.saturating_sub(*total) - } + ) -> Balance { + let batch = Prices::get(_id).unwrap(); + let value = batch[_slot as usize]; + let det = Self::determine_outlier(batch, value); + ensure!(det, Error::::NotOutlier); + let pre_total = self.total; + let total = &mut self.total; + let active = &mut self.active; + + let slash_out_of = | + total_remaining: &mut Balance, + target: &mut Balance, + value: &mut Balance, + | { + let mut slash_from_target = (*value).min(*target); + + if !slash_from_target.is_zero() { + *target -= slash_from_target; + + // don't leave a dust balance in the staking system. + if *target <= minimum_balance { + slash_from_target += *target; + *value += sp_std::mem::replace(target, Zero::zero()); + } + + *total_remaining = total_remaining.saturating_sub(slash_from_target); + *value -= slash_from_target; + } + }; + + slash_out_of(total, active, &mut value); + + let i = self.unlocking.iter_mut() + .map(|chunk| { + slash_out_of(total, &mut chunk.value, &mut value); + chunk.value + }) + .take_while(|value| value.is_zero()) // take all fully-consumed chunks out. + .count(); + + // kill all drained chunks. + let _ = self.unlocking.drain(..i); + + pre_total.saturating_sub(*total) + } } ``` -# Unit test - -Unit tests are all identical with the staking module's test in that all logics are identical regarding slash, reward and validation. - +# Unit test +Unit tests are all identical with the staking module's test in that all logics are identical regarding slash, reward and validation. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | -| 0c. | Documentation | Documentation will introduce how to nominate | -| 1. | Vault module | Vault module will declare dependancy injection trait to use session callback in `pallet-staking` module and the test code with separate `SessionManager` implementation will be provided | -| 2. | Modified Staking module | `pallet_staking` module which has two config trait for rebase callback and oracle staking callback will be provided | -| 3. | Oracle module | same as staking module including curve integration but difference in slot allocation and separate slashing verifier will be included | +| 0c. | Documentation | Documentation will introduce how to nominate | +| 1. | Vault module | Vault module will declare dependancy injection trait to use session callback in `pallet-staking` module and the test code with separate `SessionManager` implementation will be provided | +| 2. | Modified Staking module | `pallet_staking` module which has two config trait for rebase callback and oracle staking callback will be provided | +| 3. | Oracle module | same as staking module including curve integration but difference in slot allocation and separate slashing verifier will be included | | 4. | Unit test code | Unit test codes in `tests.rs` in each runtime module with separate `SessionManager` implementation | | 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of Standard protocol chain | - - ## Future Plans + - Add more prices to add from the oracle (e.g. stock prices, commodities, etc) provider -- Full function test on Kusama/Rococo. -- Full function test on Polkadot. +* Full function test on Kusama/Rococo. +* Full function test on Polkadot. -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: -- Pitch: [https://whitepaper.standardprotocol.org](https://whitepaper.standardprotocol.org) +* Pitch: [https://whitepaper.standardprotocol.org](https://whitepaper.standardprotocol.org) diff --git a/applications/Starry_Network.md b/applications/Starry_Network.md index e44ac7b822b..d54cee82bbe 100644 --- a/applications/Starry_Network.md +++ b/applications/Starry_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Starry Protocol -* **Project Name:** Starry Protocol * **Proposer:** [Starry Network](https://github.com/Starry-Network) * **Payment Address:** 0xe29DE8c6088d241647e6456F8b4755a3D0f7c8B1 diff --git a/applications/SubDAO-Chrome-Extension.md b/applications/SubDAO-Chrome-Extension.md index 9d6aa17c9ca..218b582fee8 100644 --- a/applications/SubDAO-Chrome-Extension.md +++ b/applications/SubDAO-Chrome-Extension.md @@ -1,12 +1,11 @@ -# W3F Open Grant Proposal +# SubDAO Chrome Extension -* **Project Name:** SubDAO Chrome Extension * **Team Name:** [SubDAO Labs](https://github.com/subdao-network) * **Payment Address:** 3FcJjvzazcpgmJkesdAfx333fyCudxuAe7 ## Project Overview :page_facing_up: -The previous application [SubDAO Network Application - https://github.com/w3f/Grant-Milestone-Delivery/pull/114] +The previous application [SubDAO Network Application - ] ### Overview @@ -23,7 +22,7 @@ We are the team of SubDAO Labs, and we are trying to build the ecosystem for DAO SubDAO Chrome Extension provides several features, such as Polkadot Wallet, Social Network Message, and DAO Management. ![](https://raw.githubusercontent.com/SubDAO-Network/graphics/main/start.png) -**Polkadot Wallet** +**Polkadot Wallet** A wallet is integrated as an extension of chrome, and it provides wallet management. ![](https://raw.githubusercontent.com/SubDAO-Network/graphics/main/wallet.png) @@ -35,7 +34,6 @@ It supports Twitter and Facebook messages. Thanks to [MaskBook](https://mask.io) The main goal of creating SubDAO Chrome Extension is to help users to manage their DAOs with a better user experience. ![](https://raw.githubusercontent.com/SubDAO-Network/graphics/main/DAO.png) - ### Ecosystem Fit * Where and how does your project fit into the ecosystem? @@ -67,7 +65,7 @@ There are no similar projects in the Polkadot ecosystem yet, and even we already * **Contact Name:** WannaM * **Contact Email:** subdao.lab@gmail.com -* **Website:** https://subdao.network +* **Website:** ### Legal Structure @@ -78,41 +76,44 @@ There are no similar projects in the Polkadot ecosystem yet, and even we already The team is the one who applied SubDAO. -**Qiang** - - Over 13 years of experiences in Software Development - - Chief Solution Architect in Tencent - - Former Team Lead in IBM - - Core Developer of Smart Cloud / HSLT - - Code Contributor of KVM - - Community Contributor in RedHat +**Qiang** + +* Over 13 years of experiences in Software Development +* Chief Solution Architect in Tencent +* Former Team Lead in IBM +* Core Developer of Smart Cloud / HSLT +* Code Contributor of KVM +* Community Contributor in RedHat + +**Marvin Tong** -**Marvin Tong** - - Founder and CEO of Phala Network - - Former Product Manager in Tencent - - Former Product Manager in DiDi +* Founder and CEO of Phala Network +* Former Product Manager in Tencent +* Former Product Manager in DiDi -**Dajun** +**Dajun** - - Over 12 years of experiences in Development - - Former Senior Software Engineer in Alibaba - - Core Developer of Wetez and StaFi.io +* Over 12 years of experiences in Development +* Former Senior Software Engineer in Alibaba +* Core Developer of Wetez and StaFi.io -**John Xie** +**John Xie** - - Full-stack Developer - - Over 15 years of experiences in Development and Management - - Has plenty of experience in Software Development and Blockchain Development - - Currently, focus on Cross-chain technologies +* Full-stack Developer +* Over 15 years of experiences in Development and Management +* Has plenty of experience in Software Development and Blockchain Development +* Currently, focus on Cross-chain technologies -**Tallone** - - Full-stack Developer - - Over 20 years of experiences in Product Development and Management - - Has plenty of experience in Software Architecture - - Currently focused on Blockchain Development and Cross-chain Technologies +**Tallone** + +* Full-stack Developer +* Over 20 years of experiences in Product Development and Management +* Has plenty of experience in Software Architecture +* Currently focused on Blockchain Development and Cross-chain Technologies ### Team Code Repos -* https://github.com/subdao-network +* ### Team LinkedIn Profiles @@ -121,7 +122,7 @@ The team is the one who applied SubDAO. ## Development Status :open_book: -The DAO-related smart contracts are partially implemented in the SubDAO plan. Those contracts can be found in https://github.com/SubDAO-Network/subDAO-contracts. +The DAO-related smart contracts are partially implemented in the SubDAO plan. Those contracts can be found in . We have already designed some UI/UX as the shown previous section, and the full extension relies on the features provided by SubDAO. Milestone 1 of SubDAO is already finished and accepted. @@ -144,7 +145,7 @@ The Social Network provides the feature to post encrypted messages on Twitter an ### Milestone 1 - The first published version * **Estimated Duration:** 1 month -* **FTE:** 3 +* **FTE:** 3 * **Costs:** 9,000 USD | Number | Deliverable | Specification | @@ -167,9 +168,8 @@ The Social Network provides the feature to post encrypted messages on Twitter an ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** We get this information from the w3f website. * We have made the SubDAO Network, and an open grant has been accepted. * Thanks to the Maskbook team who builds Mask book. - diff --git a/applications/SubDAO_Network.md b/applications/SubDAO_Network.md index 64d3dccee7c..0c3067a5ae8 100644 --- a/applications/SubDAO_Network.md +++ b/applications/SubDAO_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# SubDAO -* **Project:** SubDAO * **Proposer:** [SubDAO Labs](https://github.com/subdao-network) * **Payment Address:** 3FcJjvzazcpgmJkesdAfx333fyCudxuAe7 diff --git a/applications/SubDAO_PolkaSign.md b/applications/SubDAO_PolkaSign.md index 20f303cf282..ccee7832382 100644 --- a/applications/SubDAO_PolkaSign.md +++ b/applications/SubDAO_PolkaSign.md @@ -1,36 +1,31 @@ -# W3F Open Grant Proposal +# PolkaSign -* **Project Name:** PolkaSign * **Team Name:** [SubDAO Labs](https://github.com/subdao-network) * **Payment Address:** 0x0c105bA504D1905bb47EeA57FA8694893bDEd27f ## Project Overview :page_facing_up: -The previous application [SubDAO Network Application - https://github.com/w3f/Grants-Program/pull/90] +The previous application [SubDAO Network Application - ] ### Overview -The PolkaSign is a web3.0 app for electronic agreements built on top of Polkadot Ecosystem. The electronic agreement is well-known in web2.0 instead of paper agreements used thousands of years in historical time. With electronic agreements, commercial activities become much more efficient and have a lower cost than ever. The whole human world is benefiting from electronic agreements in the past 30 years. While with more and more electronic agreements signed, more and more issues are exposed. Such as electronic agreements are stored in a centralized system, fraud in electronic agreements, and so on. With PolkaSign, anyone can sign an electronic agreement with whoever he/she wants. To sign an electronic agreement, you just need to upload your agreement document, and sign it in PolkaSign, then share the link to the co-signer. +The PolkaSign is a web3.0 app for electronic agreements built on top of Polkadot Ecosystem. The electronic agreement is well-known in web2.0 instead of paper agreements used thousands of years in historical time. With electronic agreements, commercial activities become much more efficient and have a lower cost than ever. The whole human world is benefiting from electronic agreements in the past 30 years. While with more and more electronic agreements signed, more and more issues are exposed. Such as electronic agreements are stored in a centralized system, fraud in electronic agreements, and so on. With PolkaSign, anyone can sign an electronic agreement with whoever he/she wants. To sign an electronic agreement, you just need to upload your agreement document, and sign it in PolkaSign, then share the link to the co-signer. The PolkaSign is developed with Substrate Framework based on the SubDAO Network, which can be replaced with any Substrate Based Chains, and serves any kind of orgs with electronic agreements. The goal of PolkaSign is to provide electronic agreements in a web 3.0 way, to replace the systems in web 2.0. ### Project Details -PolkaSign combines blockchain and decentralized storage to provide a reliable electronic agreements platform. With the decentralized storage system, such as IPFS, Swarm, or Crust in Polkadot ecosystem, provides the storage for the agreement files, at the current state, only PDF is supported. The information of agreement, including signature, signer, agreement files list, etc., is written with smart contract on the blockchain. The PolkaSign provides a dapp to handle agreement files, co-signer, and links, to interact with decentralized storage and smart contracts on the blockchain. The smart contracts of PolkaSign are based on ink!, any substrate-based chain can adopt these smart contracts easily. +PolkaSign combines blockchain and decentralized storage to provide a reliable electronic agreements platform. With the decentralized storage system, such as IPFS, Swarm, or Crust in Polkadot ecosystem, provides the storage for the agreement files, at the current state, only PDF is supported. The information of agreement, including signature, signer, agreement files list, etc., is written with smart contract on the blockchain. The PolkaSign provides a dapp to handle agreement files, co-signer, and links, to interact with decentralized storage and smart contracts on the blockchain. The smart contracts of PolkaSign are based on ink!, any substrate-based chain can adopt these smart contracts easily. ### Workflow Below is the workflow of how to use PolkaSign. Alice wants to sign an agreement with Bob, so she creates an electronic agreement with PolkaSign, and the electronic agreement files are stored in the decentralized storage system. Then Alice adds Bob's wallet address as co-signer, and sign the contract with her private key. After that, Alice shares the information of agreement with Bob. When Bob launches PolkaSign with his wallet, he will find the very agreement waiting for him to sign. Everything is done when Bob approves and signs the agreement send from Alice in PolkaSign. - - ![Flow-2021-07-21-2311](https://raw.githubusercontent.com/WannaM/graphics/main/Flow-2021-07-21-2311.png) - - ### Design -The home page shows the list of agreements in different statuses. The current waiting for signing agreements will be display as default, and you can switch the list by tabs or filter button in the left panel. The agreement file info, the status, and the progress of the agreement are shown in the detailed info of each agreement. The draft design of PolkaSign is shown below. +The home page shows the list of agreements in different statuses. The current waiting for signing agreements will be display as default, and you can switch the list by tabs or filter button in the left panel. The agreement file info, the status, and the progress of the agreement are shown in the detailed info of each agreement. The draft design of PolkaSign is shown below. ![Overview-2021-07-21-2052](https://raw.githubusercontent.com/WannaM/graphics/main/Overview-2021-07-21-2052.png) @@ -42,19 +37,10 @@ The second step is to add co-signers. Add any number of co-signers by filling in ![AddSigner-2021-07-21-2052](https://raw.githubusercontent.com/WannaM/graphics/main/AddSigner-2021-07-21-2052.png) - - The last step is to review the contract. When everything is ready, sign it with your wallet and share the link with co-signers. - - ![Review-2021-07-21-2052](https://raw.githubusercontent.com/WannaM/graphics/main/Review-2021-07-21-2052.png) - - - - - ### Ecosystem Fit * Where and how does your project fit into the ecosystem? @@ -84,7 +70,7 @@ The project meets the need of signing contract with decentralization, immutabili * **Contact Name:** WannaM * **Contact Email:** subdao.lab@gmail.com -* **Website:** https://subdao.network +* **Website:** ### Legal Structure @@ -95,28 +81,30 @@ The project meets the need of signing contract with decentralization, immutabili The team is the one who applied SubDAO. -**Qiang** - - Over 13 years of experiences in Software Development - - Chief Solution Architect in Tencent - - Former Team Lead in IBM - - Core Developer of Smart Cloud / HSLT - - Code Contributor of KVM - - Community Contributor in RedHat +**Qiang** -**Marvin Tong** - - Founder and CEO of Phala Network - - Former Product Manager in Tencent - - Former Product Manager in DiDi +* Over 13 years of experiences in Software Development +* Chief Solution Architect in Tencent +* Former Team Lead in IBM +* Core Developer of Smart Cloud / HSLT +* Code Contributor of KVM +* Community Contributor in RedHat -**Dajun** +**Marvin Tong** - - Over 12 years of experiences in Development - - Former Senior Software Engineer in Alibaba - - Core Developer of Wetez and StaFi.io +* Founder and CEO of Phala Network +* Former Product Manager in Tencent +* Former Product Manager in DiDi + +**Dajun** + +* Over 12 years of experiences in Development +* Former Senior Software Engineer in Alibaba +* Core Developer of Wetez and StaFi.io ### Team Code Repos -* https://github.com/subdao-network +* ### Team LinkedIn Profiles @@ -129,7 +117,7 @@ We have already designed some UI/UX as the shown previous section, and the rest ## Development Roadmap :nut_and_bolt: -We planned two major versions. +We planned two major versions. Version 1: The goal of first version is to provide a usable PolkaSign, the users can upload PDF agreement files and co-sign with other signers. It contains the features of store agreement files in decentralized storage, sign contract with smart contract, sharing the contracts waiting for sign. @@ -137,18 +125,16 @@ Version 2: The goal of second version is to provide a common PolkaSign for other ### Overview -In this application, we planned to provide the first version of PolkaSign. The main features are 1) store agreement files in decentralized storage, 2) sign contract with smart contract and 3) sharing the contracts waiting for sign. It will contains smart contract with ink!, web app as client and codes to interact with decentralized storage system. +In this application, we planned to provide the first version of PolkaSign. The main features are 1) store agreement files in decentralized storage, 2) sign contract with smart contract and 3) sharing the contracts waiting for sign. It will contains smart contract with ink!, web app as client and codes to interact with decentralized storage system. * **Total Estimated Duration:** 2 month * **Full-Time Equivalent (FTE):** 2 * **Total Costs:** 15,000 USD - - ### Milestone 1 - The first usable version * **Estimated Duration:** 2 month -* **FTE:** 2 +* **FTE:** 2 * **Costs:** 15,000 USD | Number | Deliverable | Specification | @@ -170,7 +156,7 @@ In this application, we planned to provide the first version of PolkaSign. The m ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** We get this information from the w3f website. * We have made the SubDAO Network, and an open grant has been accepted. diff --git a/applications/SubGame_Network.md b/applications/SubGame_Network.md index bfba7857e8f..9676d656f7f 100644 --- a/applications/SubGame_Network.md +++ b/applications/SubGame_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# SubGame Network -* **Project Name:** SubGame Network * **Team Name:** [SubGame-Network](https://github.com/SubGame-Network) * **Payment Address:** 3CK6HN4y2ZEKX7JMfdegds7B7GrUSmv65c @@ -121,16 +120,16 @@ No Legal Entity | 1a. | SubGame Node | Provide node compilation and installation instructions, start the test network| | 2a. | pallet-chips | The Chips module has been developed and you can use Chips to participate in the game | | | Storage: | `Chips get(fn get_chips): map hasher(blake2_128_concat) T::AccountId => u32;` | -| | Function: | 1)`pub fn transfer_chips(origin,chips:u32)->dispatch::DispatchResult`

          2)`pub fn sgt_to_chips(origin,pay:T::Balance)->dispatch::DispatchResult` | +| | Function: | 1)`pub fn transfer_chips(origin,chips:u32)->dispatch::DispatchResult`

          2)`pub fn sgt_to_chips(origin,pay:T::Balance)->dispatch::DispatchResult` | | 2b. | pallet-gametemplates | Complete the basic module design and development of the template library, and complete the first game template | -| | Storage:| `Templates get(fn get_templates): Vec