diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index b8eacc22228..fa6dda08953 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -14,7 +14,8 @@
- [x] The [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md) has been copied and aptly renamed (`project_name.md`).
- [ ] I have read the [application guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/grant_guidelines_per_category.md).
-- [ ] Payment details have been provided (bank details via email _or_ Polkadot (USDC & USDT) or BTC address in the application).
+- [ ] Payment details have been provided (bank details via email _or_ Polkadot (USDC & USDT) address in the application).
+- [ ] I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
- [ ] The software delivered for this grant will be released under an open-source license specified in the application.
- [ ] The initial PR contains only one commit (squash and force-push if needed).
- [ ] The grant will only be announced once the first milestone [has been accepted](https://github.com/w3f/Grant-Milestone-Delivery#process) (see the [announcement guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/announcement-guidelines.md)).
diff --git a/.github/workflows/check_application_document.yml b/.github/workflows/check_application_document.yml
index 78c841442ee..84c3a37bfae 100644
--- a/.github/workflows/check_application_document.yml
+++ b/.github/workflows/check_application_document.yml
@@ -6,30 +6,6 @@ on:
types: [opened, synchronize]
jobs:
- discussion_private:
- if: |
- github.event.action == 'opened' &&
- contains(github.event.pull_request.body, 'Project Abstract') && (
- !contains(github.event.pull_request.body, '- [ ] I prefer the discussion') ||
- (
- contains(github.event.pull_request.body, '- [ ] I prefer the discussion') &&
- !contains(github.event.pull_request.body, '@_______:matrix.org')
- )
- )
- runs-on: ubuntu-latest
- steps:
- - name: Add 'discussion private' label if the application is private
- uses: actions/github-script@v6
- with:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- script: |
- github.rest.issues.addLabels({
- issue_number: context.issue.number,
- owner: context.repo.owner,
- repo: context.repo.repo,
- labels: ["discussion private"]
- })
-
get_filename:
if: contains(github.event.pull_request.body, 'Project Abstract')
runs-on: ubuntu-latest
@@ -44,15 +20,29 @@ jobs:
filter: 'applications/*.md'
format: 'csv'
+ add_label:
+ needs: get_filename
+ if: needs.get_filename.outputs.filename
+ runs-on: ubuntu-latest
+ permissions:
+ pull-requests: write
+ steps:
+ - name: add admin-review label
+ uses: actions-ecosystem/action-add-labels@v1
+ with:
+ labels: admin-review
+ github_token: ${{ secrets.GITHUB_TOKEN }}
+
parse_document:
needs: get_filename
if: needs.get_filename.outputs.filename
runs-on: ubuntu-latest
+ permissions:
+ pull-requests: write
+ issues: write
steps:
-
- name: Checkout
uses: actions/checkout@v2
-
- name: Parse application file
id: grant_parser
uses: w3f/parse-grant-application-action@master
diff --git a/.github/workflows/check_broken_links.yml b/.github/workflows/check_broken_links.yml
new file mode 100644
index 00000000000..326b1545359
--- /dev/null
+++ b/.github/workflows/check_broken_links.yml
@@ -0,0 +1,29 @@
+name: Broken Links
+
+on:
+ repository_dispatch:
+ workflow_dispatch:
+ schedule:
+ - cron: '0 0 1 * *' # Trigger the workflow every month
+
+jobs:
+ build_and_check:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: actions/checkout@v3
+
+ - name: Link Checker
+ id: lychee
+ uses: lycheeverse/lychee-action@v1.8.0
+ env:
+ GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
+ with:
+ args: --verbose --no-progress !./applications/*
+
+ - name: Create Issue From File
+ if: env.lychee_exit_code != 0
+ uses: peter-evans/create-issue-from-file@v4
+ with:
+ title: Link Checker Report
+ content-filepath: ./lychee/out.md
+ labels: report, automated issue
diff --git a/.github/workflows/enforce-label.yml b/.github/workflows/enforce-label.yml
new file mode 100644
index 00000000000..77179753ae6
--- /dev/null
+++ b/.github/workflows/enforce-label.yml
@@ -0,0 +1,13 @@
+name: Enforce PR labels
+
+on:
+ pull_request:
+ types: [labeled, unlabeled, opened, edited, synchronize]
+jobs:
+ enforce-label:
+ runs-on: ubuntu-latest
+ steps:
+ - uses: yogevbd/enforce-label-action@2.1.0
+ with:
+ BANNED_LABELS: "admin-review"
+ BANNED_LABELS_DESCRIPTION: "Remove `admin-review` label for merge"
diff --git a/.github/workflows/private-labeler.yml b/.github/workflows/private-labeler.yml
new file mode 100644
index 00000000000..096debb3496
--- /dev/null
+++ b/.github/workflows/private-labeler.yml
@@ -0,0 +1,30 @@
+name: Check for private discussion
+
+on:
+ workflow_dispatch:
+ pull_request:
+ types: [opened, edited]
+
+jobs:
+ discussion_private:
+ if: |
+ contains(github.event.pull_request.body, 'Project Abstract') && (
+ !contains(github.event.pull_request.body, '- [ ] I prefer the discussion') ||
+ (
+ contains(github.event.pull_request.body, '- [ ] I prefer the discussion') &&
+ !contains(github.event.pull_request.body, '@_______:matrix.org')
+ )
+ )
+ runs-on: ubuntu-latest
+ steps:
+ - name: Add 'discussion private' label if the application is private
+ uses: actions/github-script@v6
+ with:
+ github-token: ${{ secrets.GITHUB_TOKEN }}
+ script: |
+ github.rest.issues.addLabels({
+ issue_number: context.issue.number,
+ owner: context.repo.owner,
+ repo: context.repo.repo,
+ labels: ["discussion private"]
+ })
diff --git a/README.md b/README.md
index 83209ceafe4..39497ff3d8a 100644
--- a/README.md
+++ b/README.md
@@ -40,7 +40,7 @@ Anyone is welcome to apply for a grant. Projects funded through our programs are
Generally, your project will have better chances to be accepted if:
-- It presents a **well-researched** or tested concept, for which ideally you are able to show some prior work.
+- It presents a **well-researched** or tested concept, for which, ideally, you are able to show some prior work.
- You can demonstrate that the project will be **maintained** after completion of the grant, be it through an obvious commitment to the technology from your side, additional funding sources, or an existing business model.
- Your team has **proven experience** with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine for past activity and code quality. Naturally, you can also link to projects on other platforms.
- Your application is **rich in technical details** and well-defined.
@@ -50,9 +50,9 @@ 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.
+- Applications must not mention a specific token. Furthermore, the focus of the application should lie on the software that is being implemented/research being carried out as part of the grant and less on your project/venture/operation. For the purpose of the application and delivery, think about how others might also benefit from your work.
- As a general rule, teams are asked to finish a grant before applying for another one.
-- Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering or criminal activities in general.
+- Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering, or criminal activities in general.
In addition to the information provided on your application, note that your project will need to comply with our [Guidelines for Milestone Deliverables](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/milestone-deliverables-guidelines.md). In particular, we require all projects to create documentation that explains how their project works. At a minimum, _written_ documentation is required for funding. Tutorials or videos are also helpful for new users to understand how to use your product.
@@ -82,19 +82,16 @@ For questions about the grants program itself, see our [FAQ](docs/faq.md#frequen
#### W3F Grants Committee
-The committee consists of individuals who know the funding priorities of the Polkadot ecosystem, and is responsible for evaluating grant applications and providing feedback on these.
+The committee consists of individuals who know the funding priorities of the Polkadot ecosystem and is responsible for evaluating grant applications and providing feedback on these.
In cases where a niche expert opinion is desirable, one of the committee members may request such a review.
- [Santiago Balaguer](https://github.com/SBalaguer)
- [Aeron Buchanan](https://github.com/aeronbuchanan)
-- [Gautam Dhameja](https://github.com/gautamdhameja)
- [David Hawig](https://github.com/Noc2)
-- [Diogo Mendonça](https://github.com/dsm-w3f)
- [Sebastian Müller](https://github.com/semuelle)
- [Bill Laboon](https://github.com/laboon)
- [Keegan Quigley](https://github.com/keeganquigley)
-- [Nikhil Ranjan](https://github.com/nikw3f)
- [Raul Romanutti](https://github.com/rrtti)
- [Seraya Takahashi](https://github.com/takahser)
- [Benjamin Weiß](https://github.com/BenWhiteJam)
@@ -105,10 +102,8 @@ 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.
- [David Hawig](https://github.com/Noc2)
-- [Diogo Mendonça](https://github.com/dsm-w3f)
- [Sebastian Müller](https://github.com/semuelle)
- [Keegan Quigley](https://github.com/keeganquigley)
-- [Nikhil Ranjan](https://github.com/nikw3f)
- [Seraya Takahashi](https://github.com/takahser)
#### W3F Operations Team
@@ -116,7 +111,6 @@ Evaluators are individuals able to evaluate the technology delivered as a result
The Operations Team takes care of legal documents, invoicing, and remittances.
- [Melanie Diener](https://github.com/meldien)
-- [Federica Dubbini](https://github.com/fededubbi)
- [Rouven Pérez](https://github.com/RouvenP)
@@ -147,7 +141,7 @@ The W3F Grants Program offers different grant levels to help you best, depending
## :pencil: Process
-> **:loudspeaker:** Payments can be made in USDT and USDC on the Polkadot [AssetHub](https://wiki.polkadot.network/docs/learn-assets), Bitcoin, and fiat (USD, EUR, CHF). Please indicate your preference in the application [as outlined in our application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md?plain=1#L7). If you want to apply in **private**, you can do so [:arrow_right: here](https://docs.google.com/forms/d/e/1FAIpQLSfMfjiRmDQDRk-4OhNASM6BAKii7rz_B1jWtbCPkUh6N7M2ww/viewform). Note that this is generally a slower process and imposes stricter requirements on applicants.
+> **:loudspeaker:** Payments can be made in USDT and USDC on the Polkadot [AssetHub](https://wiki.polkadot.network/docs/learn-assets) and fiat (USD, EUR, CHF). Please indicate your preference in the application [as outlined in our application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md?plain=1#L7). If you want to apply in **private**, you can do so [:arrow_right: here](https://docs.google.com/forms/d/e/1FAIpQLSfMfjiRmDQDRk-4OhNASM6BAKii7rz_B1jWtbCPkUh6N7M2ww/viewform). Note that this is generally a slower process and imposes stricter requirements on applicants.
### 1. Application
@@ -222,7 +216,7 @@ 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 or USDT/USDC on Polkadot AssetHub.
+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 USDT/USDC on Polkadot AssetHub after delivery and approval of the first milestone.
## :bulb: Help
@@ -320,8 +314,10 @@ Below is a list of other grant and bounty programs in the Polkadot/Substrate eco
- [Acala Grants Program](https://acala.network/ecosystem-program)
- [Aleph Zero Funding Program](https://alephzero.org/ecosystem-funding-program)
- [Astar / Shiden Network Builders Program](https://github.com/PlasmNetwork/Builders-Program)
+- [Avail Uncharted Grants](https://github.com/availproject/avail-uncharted/blob/main/grants/grants.md)
- [Crust Grants Program](https://github.com/crustio/Crust-Grants-Program)
- [Darwinia Grants Program](https://github.com/darwinia-network/collaboration/blob/master/grant/README.md#grant-program)
+- [Decentralized Futures Program](https://futures.web3.foundation/)
- [Edgeware Grants and Bounties](https://gov.edgewa.re/discussion/1132-edgeware-proposal-process-and-template)
- [HydraDX Grants and Bounties](https://docs.hydradx.io/spending_fw/)
- [ink!ubator](https://use.ink/ubator/)
diff --git a/applications/CILA-omnichain-infrastructure.md b/applications/CILA-omnichain-infrastructure.md
index 208632f1bad..227987718b2 100644
--- a/applications/CILA-omnichain-infrastructure.md
+++ b/applications/CILA-omnichain-infrastructure.md
@@ -3,6 +3,7 @@
- **Team Name:** Collective Intelligence Labs
- **Payment Address:** bc1qff0kjc6pyjkneyt3pctm5nahjpd9f774avz55x (BTC)
- **Level:** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1679#issuecomment-1823419675)
## Project Overview :page_facing_up:
diff --git a/applications/Calamar.md b/applications/Calamar.md
index a7953c14400..ff52a1eae69 100644
--- a/applications/Calamar.md
+++ b/applications/Calamar.md
@@ -69,26 +69,31 @@ As we are gathering feedback, one of the most important features for the users s
- account's name if set
- owned assets accross all listed chains, including dollar values and graphs for visualization.
- list all chain-specific addresses
- - list all related transfers, XCM transfers, extrinsics and calls
+ - list all related transfers, extrinsics and calls
-
+
#### Chain dashboards
Each chain will have own dashboard with statistics and listing of latest blocks, latest transfers, top holders, etc. It makes the explorer more useful even for users who are not searching for specific items.
-
+
-#### Cross-chain transfers
-Important feature is to create good UI for displaying information about XCM teleports and other cross-chain transfers where you can easily see all involved sides (chains, accounts) and other useful data.
+#### Metadata explorer
-- XCM transfer detail
+The runtime metadata of each chain are still evolving and changing but it is not so easy to display them in a structured and human-readable way. There is e.g. a tool https://wiki.polkadot.network/docs/metadata which displays them but only latest version and supports only a few networks. The metadata explorer we are going to implement will support all the networks and also historical versions of the runtime spec.
-
+
-- in transfers table
+#### Item metadata
-
+The metadata information will be deeply integrated into whole Calamar so we can display it in the detail pages of the items. E.g. in extrinsic's detail page we will show info for the call name, error, parameters and link to the metadata explorer for more info.
+
+
+
+#### Search input autocomplete for call and event names
+
+Thanks to the metadata we can also autocomplete and suggest the call and event names when typing into the search input.
### Technology stack
@@ -203,7 +208,7 @@ Even though we have the already working application, there are still many things
| 10. | Website polishing | Add useful information to the website (footer with team logos, contact information, terms, etc.). |
| 11. | Polkadot.js integration | Create a PR to integrate links to the Calamar Explorer into Polkadot.js app. |
-### Milestone 2 - Account detail & Cross-chain transfers
+### Milestone 2 - Account detail & Chain dashboards
- **Estimated duration:** 4 weeks
- **FTE:** 1
@@ -232,10 +237,10 @@ In this milestone we are going to improve [account detail](#account-detail) page
| 10. | Chain dashboard / Top holders | Add top holders list table |
-### Milestone 3 - Universal search & Chain dashboards
+### Milestone 3 - Universal search & Metadata explorer
-- **Estimated duration:** 3 weeks
-- **FTE:** 1
+- **Estimated duration:** 8 weeks
+- **FTE:** 0.375
- **Costs:** $7,500
In this milestone we are going to implement [universal search](#universal-search) and one of the most requested features: [cross-chain transfers](#cross-chain-transfers) detection.
@@ -248,12 +253,16 @@ In this milestone we are going to implement [universal search](#universal-search
| 0d. | Docker | *N/A - will be provided by the first milestone.* |
| 0e. | Article | We will publish an article that explains what was done as part of the grant |
| 1. | Universal search | Search items through all the chains without the knowledge where it belongs. See [Universal search](#universal-search). |
-| 2. | XCM transfers and teleports | Detect cross-chain transfers and display relevant information of involved chains and accounts: from chain, to chain, relayed at chain (reserve), sender, beneficiary, etc. Also add their listings to account detail and chain dashboard. See [Cross-chain transfers](#cross-chain-transfers) for more. |
+| 2. | Metadata explorer | UI interface for exploring metadata retrieved from network's latest and historical versions of runtime spec. See [Metadata explorer](#metadata-explorer).
+| 3. | Show related runtime metadata in items' detail | Show related metadata information directly in detail pages of individual items and interlink to metadata explorer. See [Item metadata](#item-metadata).
+| 4. | Search input autocomplete | Autocomplete extrinsic and event name in the search input. See [Search input autocomplete for call and event names](#search-input-autocomplete-for-call-and-event-names).
## Future Plans
There is a huge potential for future improvements which the Polkadot's community can benefit from.
+We would like to definitely display information about XCM transfers and teleports.
+
As developers of most parachains implement their own custom modules/pallets it opens the opportunity to cooperate and customize Calamar explorer with UI/UX components and logic tailored to their needs.
It relates to various XCM transactions which makes it even more complex and the more types will our explorer support the more it makes the users' lives easier.
diff --git a/applications/Claps.md b/applications/Claps.md
index 885da5632f0..200d8c0b6b8 100644
--- a/applications/Claps.md
+++ b/applications/Claps.md
@@ -3,6 +3,7 @@
- **Team Name:** Taiwan Research-based Biopharmaceutical Manufacturers Association
- **Payment Address:** 0x39D3E0c7AAcfbCa133f08cfb153B4888fd36bA9B (DAI)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1440#issuecomment-1773610786)
## Overview
diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests_2.md b/applications/CoinFabrik_On_Ink_Integration_Tests_2.md
new file mode 100644
index 00000000000..684228a91ea
--- /dev/null
+++ b/applications/CoinFabrik_On_Ink_Integration_Tests_2.md
@@ -0,0 +1,182 @@
+# CoinFabrik On Ink Integration Tests 2
+- **Team Name:** CoinFabrik (Nektra S.A)
+- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+We have discovered that integration tests for ink! contracts lack some of the functionalities, or present implementation differences, when compared to E2E testing.
+
+Integration tests run significantly faster than E2E (end-to-end) tests. If a full range of functionalities were provided, it could reduce testing and QA times.
+
+Our intention is to `flatten the anvil` of ink! integration testing. With a properly flattened anvil, quality tools can be built.
+
+
+### Project Details
+
+We have conducted a comprehensive analysis to identify any missing functionalities in integration tests and implementation differences with E2E tests, and to propose and develop new testing features based on our findings. This analysis was carried as part of a previous grant ([link](https://github.com/w3f/Grant-Milestone-Delivery/pull/998)).
+
+With this new grant, our objective is to implement our findings. Specifically, we aim to address functions in integration testing that have missing implementations or show differences when compared to e2e tests. We will add our contributions into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
+
+### Ecosystem Fit
+
+Having a comprehensive set of functionalities available for integration tests would bring numerous benefits to the entire community, including improved reliability, code quality and maturity, and faster feedback loops.
+
+Integration tests are useful during their development and they are quicker than E2E tests. We learned this while working on fuzzing detection techniques during the [Proof of Concept of Scout](https://github.com/CoinFabrik/web3-grant), which we performed in collaboration with [researchers from the University of Buenos Aires](https://lafhis.dc.uba.ar/home). We believe that having a complete set of functionalities for integration tests would be useful for other teams working in the development of ink! smart contracts.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Ariel Wassbein, Head of Research.
+- Agustin Aon, Technical Lead.
+- Valeria Caracciolo, Business Development.
+- CoinFabrik's development and QA teams.
+
+### Contact
+
+- **Contact Name:** Valeria Caracciolo
+- **Contact Email:** valeria.caracciolo@coinfabrik.com
+- **Website:** https://www.coinfabrik.com/
+
+### Legal Structure
+
+- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina.
+- **Registered Legal Entity:** Nektra S.A.
+
+### Team's experience
+
+We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 200 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL.
+
+Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires.
+
+As well, CoinFabrik has been providing Quality Assurance as a service to development teams, accumulating valuable expertise in the field for a considerable period of time. Our clients highly appreciate this service, and as a result, we are eager to expand our capabilities to the ink! ecosystem.
+
+
+### Team Code Repos
+
+- https://github.com/CoinFabrik
+- https://github.com/CoinFabrik/on-ink-integration-tests
+- https://github.com/CoinFabrik/scout
+- https://github.com/CoinFabrik/web3-grant
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/arielwaissbein/
+- https://www.linkedin.com/in/agustin-aon/
+- https://www.linkedin.com/in/valeriacaracciolo/
+
+
+## Development Status :open_book:
+
+We have identified 24 functions exposed for their usage in integration and E2E tests in the file [env_access.rs](https://github.com/paritytech/ink/blob/master/crates/ink/src/env_access.rs) of the ink! repository. Of these 24 functions, we determined that there are 9 functions to work on with explicit plans, and 13 functions for which there might be implementation differences that remain to be analyzed. Two functions were deemed unfeasible for their implementation in the integration testing environment.
+
+
+**Table 1: Status of functions exposed in integration and e2e testing environments.**
+| Issue Number | Function | Implemented Integration Tests | Implemented Integration E2E Tests | Status |
+|--------------|-----------------------------|-------------------------------|------------------------|------------------------------------------------------------------------------------------------|
+| 1 | default_accounts() | Yes | Yes | Implementation Difference. |
+| 2 | set_contract_storage() | Yes | Yes | Missing limitation on Integration Testing. |
+| 3 | invoke_contract_delegate() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 4 | invoke_contract() | No | Yes | Missing Function Implementation on Integration Testing |
+| 5 | gas_left() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. |
+| 6 | set_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 7 | instantiate_contract() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 8 | caller_is_origin() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 9 | code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 10 | own_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 11 | call_runtime() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. |
+| 12 | caller() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 13 | transferred_value() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 14 | weight_to_fee() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 15 | block_timestamp() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 16 | account_id() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 17 | balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 18 | block_number() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 19 | minimum_balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 20 | terminate_contract() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 21 | transfer() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 22 | hash_bytes() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 23 | hash_encoded() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+| 24 | ecdsa_recover() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. |
+
+For these two sets of functions, with explicit implementation plans and pending analysis, the following work remains to be performed.
+- The implementation and correction of implementation differences of the 9 functions with explicit plans. These are the functions with issue numbers 1, 2, 3, 4, 6, 7, 8, 9, 10.
+- An analysis of the remaining 13 functions, which are implemented both for integration and E2E tests, in order to first estimate and then correct implementation differences (if any). These correspond to functions issue numbers 12 through 24.
+- QA: Adding tests to integrate the functions we add or modify to the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
+- Report Describing our Contribution.
+
+Considering the dependency of several functions on the implementation of `instantiate_contract()`, we propose to split the work above into two milestones. All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
+
+We have also identified a bug in the e2e tests. When contracts are in a workspace with dependencies defined in `Cargo.toml`, and these dependencies are inherited in contracts, the e2e tests fail to compile. However, manually specifying dependencies in each contract resolves the issue. We've logged this bug on GitHub [Issue #1919](https://github.com/paritytech/ink/issues/1919) and will be addressing it as part of our work in Milestone 1.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 4 weeks
+- **Full-Time Equivalent (FTE):** 4 FTE
+(0.50 Project Manager,
+0.50 Tech Lead,
+1 Full time Sr Rust Developer,
+1 Full Time SemiSr Rust Developer,
+1 Full Time QA Specialist)
+- **Total Costs:** 30,000 USD
+
+### Milestone 1: Execution and Further Analysis
+- **Estimated duration:** 4 weeks
+- **FTE:** 4
+- **Costs:** 30,000 USD
+
+| Number | Deliverable | Specification |
+| ----- | ----------- | ------------- |
+| 0a. | License | MIT
+| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the functions to be implemented/corrected in this milestone, corresponding to issues 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract().
Documentation and test cases will be provided for the 13 functions with remaining analysis. If implementation differences are found in these functions, an estimate for their correction and an implementation idea will also be provided in our report.
If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing.
+| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included.
+| 0d. | Docker | Does not apply at this stage.
+| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/.
+ **1** | Develop | We will develop the missing functionalities or correct implementation differences for functions 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract(). All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing.
+ **2** | Review and Estimate | We will review the remaining 13 unanalysed functions, which are implemented both for integration and e2e tests. For these functions we will provide documentation, a test case and an implementation estimation if applicable. These correspond to functions issue numbers 12 through 24.
+ **3** | Quality Assurance | We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink).
+
+
+
+## Future Plans
+
+After finishing the Milestone 1: Execution and Further Analysis, we will submit a new grant proposal to continue with the implementation of the remaining functions. We will include specific references to developments associated with the estimations resulting from the further analysis of functions issue numbers 12 through 24.
+
+### Next Milestone: Execution
+- **Estimated duration:** 4 weeks
+- **FTE:** 4
+- **Costs:** 30,000 USD
+
+
+
+| Number | Deliverable | Specification |
+| ----- | ----------- | ------------- |
+| 0a. | License | MIT
+| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().
Our report will also document the implementation of any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work that was required in order to ensure consistency between integration and e2e tests.
If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing.
+| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included.
+| 0d. | Docker | Does not apply at this stage.
+| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/.
+ **1** | Development | We will implement the missing functionalities or resolve implementation differences for function issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().
We will implement any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work required in order to ensure consistency between integration and e2e tests.
All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing.
+**2** | Quality Assurance| We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink).
+
+
+Moving forward, we have two projects in mind:
+
+- Research and develop an advanced testing automation solution for ink! smart contracts.
+- Improve our open source bug-detection tool [Scout](https://coinfabrik.github.io/scout/ ).
+
+
+
+## Referral Program (optional) :moneybag:
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result.
+
+During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation.
+
diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests_3.md b/applications/CoinFabrik_On_Ink_Integration_Tests_3.md
new file mode 100644
index 00000000000..bd630b24b5d
--- /dev/null
+++ b/applications/CoinFabrik_On_Ink_Integration_Tests_3.md
@@ -0,0 +1,159 @@
+# CoinFabrik On Ink Integration Tests 3
+- **Team Name:** CoinFabrik (Nektra S.A)
+- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+We have discovered that integration tests for ink! contracts lack some of the functionalities, or present implementation differences, when compared to E2E testing.
+
+Integration tests run significantly faster than E2E (end-to-end) tests. If a full range of functionalities were provided, it could reduce testing and QA times.
+
+Our intention is to `flatten the anvil` of ink! integration testing. With a properly flattened anvil, quality tools can be built.
+
+
+### Project Details
+
+We have conducted a comprehensive analysis to identify any missing functionalities in integration tests and implementation differences with E2E tests, and to propose and develop new testing features based on our findings. This analysis was carried as part of two previous grants ([link1](https://github.com/w3f/Grant-Milestone-Delivery/pull/998), [link2](https://github.com/w3f/Grant-Milestone-Delivery/pull/1043)). As part of the latter grant, we have developed and resolved the issues with some of the functions with implementation differences or missing implementations: `default_accounts()`, `set_contract_storage()` and `instantiate_contract()`.
+
+With this new grant, our objective is to implement our findings. Specifically, we aim to address functions in integration testing that have missing implementations or show differences when compared to e2e tests. We will add our contributions into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
+
+
+### Ecosystem Fit
+
+Having a comprehensive set of functionalities available for integration tests would bring numerous benefits to the entire community, including improved reliability, code quality and maturity, and faster feedback loops.
+
+Integration tests are useful during their development and they are quicker than E2E tests. We learned this while working on fuzzing detection techniques during the [Proof of Concept of Scout](https://github.com/CoinFabrik/web3-grant), which we performed in collaboration with [researchers from the University of Buenos Aires](https://lafhis.dc.uba.ar/home). We believe that having a complete set of functionalities for integration tests would be useful for other teams working in the development of ink! smart contracts.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Ariel Wassbein, Head of Research.
+- Valeria Caracciolo, Business Development.
+- CoinFabrik's development and QA teams.
+
+
+### Contact
+
+- **Contact Name:** Valeria Caracciolo
+- **Contact Email:** valeria.caracciolo@coinfabrik.com
+- **Website:** https://www.coinfabrik.com/
+
+
+### Legal Structure
+
+- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina
+- **Registered Legal Entity:** Nektra S.A
+
+
+### Team's experience
+
+We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 200 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL.
+
+Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires.
+
+As well, CoinFabrik has been providing Quality Assurance as a service to development teams, accumulating valuable expertise in the field for a considerable period of time. Our clients highly appreciate this service, and as a result, we are eager to expand our capabilities to the ink! ecosystem.
+
+
+### Team Code Repos
+
+- https://github.com/CoinFabrik
+- https://github.com/CoinFabrik/on-ink_implementations
+- https://github.com/CoinFabrik/on-ink-integration-tests
+- https://github.com/CoinFabrik/scout
+- https://github.com/CoinFabrik/web3-grant
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/arielwaissbein/
+- https://www.linkedin.com/in/valeriacaracciolo/
+
+
+## Development Status :open_book:
+
+We have identified and analyzed 24 functions exposed for their usage in integration and E2E tests in the file [env_access.rs](https://github.com/paritytech/ink/blob/master/crates/ink/src/env_access.rs) of the ink! repository. We documented these functions and provided test cases comparing their behaviour in integration and end-to-end tests. This analysis can be found in our [analysis repository](https://github.com/CoinFabrik/on-ink-integration-tests).
+
+Of these 24 functions, 4 functions showed behaviour differences when comparing their implementations for integration and e2e tests, 9 showed missing implementations for integration tests and the remaining 11 functions showed a consistent implementation across both environments.
+
+In the table below, we provide the status of each function after the developments and analysis made in our previous milestones.
+
+**Table 1: Status of functions exposed in integration and e2e testing environments.**
+| Issue Number | Function | Implemented Integration Tests | Implemented E2E Tests | Status |
+|--------------|-------------------------------|-------------------------------|----------------------------------|--------------------------------------------------------------------------|
+| 1 | default_accounts() | Yes | Yes | Implementation Difference Corrected. [Pull request performed](https://github.com/paritytech/ink/pull/1955). |
+| 2 | set_contract_storage() | Yes | Yes | Missing limitation on Integration Testing Implemented. [Pull request performed](https://github.com/paritytech/ink/pull/1961). |
+| 3 | invoke_contract_delegate() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 4 | invoke_contract() | No | Yes | Missing Function Implementation on Integration Testing |
+| 5 | gas_left() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. |
+| 6 | set_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 7 | instantiate_contract() | No. [Pull request performed](https://github.com/paritytech/ink/pull/1963). | Yes | Missing Function Implementation on Integration Testing Performed. [Pull request performed](https://github.com/paritytech/ink/pull/1963). |
+| 8 | caller_is_origin() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 9 | code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 10 | own_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. |
+| 11 | call_runtime() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. |
+| 12 | caller() | Yes | Yes | Ok. No difference observed in testing. |
+| 13 | transferred_value() | Yes | Yes | Ok. No difference observed in testing. |
+| 14 | weight_to_fee() | Yes | Yes | Implementation Difference. |
+| 15 | block_timestamp() | Yes | Yes | Ok. No difference observed in testing. |
+| 16 | account_id() | Yes | Yes | Ok. No difference observed in testing. |
+| 17 | balance() | Yes | Yes | Implementation Difference. |
+| 18 | block_number() | Yes | Yes | Ok. No difference observed in testing. |
+| 19 | minimum_balance() | Yes | Yes | Ok. No difference observed in testing. |
+| 20 | terminate_contract() | Yes | Yes | Ok. No difference observed in testing. |
+| 21 | transfer() | Yes | Yes | Ok. No difference observed in testing. |
+| 22 | hash_bytes() | Yes | Yes | Ok. No difference observed in testing. |
+| 23 | hash_encoded() | Yes | Yes | Ok. No difference observed in testing. |
+| 24 | ecdsa_recover() | Yes | Yes | Ok. No difference observed in testing. |
+
+In this milestone, we will develop the remaining functions that either lack implementations in integration tests or exhibit differences in implementation when compared to E2E tests. However, we will make exceptions for `gas_left()` and `call_runtime()`, as our analysis has deemed implementing these functions in integration tests unfeasible.
+
+**Observations for function `weight_to_fee()`:**
+
+For the function `weight_to_fee()`, we have observed in the [milestone report of our previous grant delivery](https://github.com/CoinFabrik/on-ink-integration-tests/blob/milestone-on-ink-integration-tests-2/assets/On-Ink-Integration-Tests-2-Milestone-Report.pdf) and in the provided [test case](https://github.com/CoinFabrik/on-ink-integration-tests/tree/main/test-cases/weight-to-fee) that the value obtained in e2e tests is fixed at 0 and cannot be modified. This incorrect behaviour of `weight_to_fee()` in E2E tests is also observed in paritytech/substrate-contracts-node.
+
+We have reviewed the function `weight_to_fee()` and found that it has multiple implementations. This complexity makes it challenging to identify which implementation is responsible for the E2E tests, especially given that the large size of the runtime significantly slows down debugging.
+
+To address this issue, we will submit an initial report to the ink! development team in the first week of this milestone and collaborate to devise an implementation plan. If we deem a resolution feasible, we will include it as part of this milestone.
+
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 4 weeks
+- **Full-Time Equivalent (FTE):** 4 FTE (0.50 Project Manager, 0.50 Tech Lead, 1 Full time Sr Rust Developer, 1 Full Time SemiSr Rust Developer, 1 Full Time QA Specialist)
+- **Total Costs:** 30,000 USD
+
+### Milestone 1: Execution
+- **Estimated duration:** 4 weeks
+- **FTE:** 4
+- **Costs:** 30,000 USD
+
+| Number | Deliverable | Specification |
+| ----- | ----------- | ------------- |
+| 0a. | License | MIT
+| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`, `9-code_hash()`, `10-own_code_hash()`, and `17-balance()`.
In the first week of this milestone, we will contact the ink! development team to provide an initial report on `14-weight_to_fee()`, documenting our efforts to identify the source of its implementation issues and seeking collaboration to assess the feasibility of resolving them. We will document any progress and implementations related to `14-weight_to_fee()` in our final milestone report.
We will document any additional work that was required in order to ensure consistency between integration and e2e tests.
If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the `env_access.rs` file, but that could be related to integration or e2e testing.
+| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included.
+| 0d. | Docker | Does not apply at this stage.
+| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/.
+ **1** | Development | We will implement the missing functionalities or resolve implementation differences for function issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`, `9-code_hash()`, `10-own_code_hash()` and `17-balance()`.
We will also make the necessary changes to address the issues highlighted in our initial report on `14-weight_to_fee()`, provided that these changes are deemed feasible during our discussions with the ink! development team.
All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).
If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the `env_access.rs` file that might be related to integration or end-to-end testing.
+**2** | Quality Assurance| We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink).
+
+
+## Future Plans
+
+Moving forward, we have two projects in mind:
+- Research and develop an advanced testing automation solution for ink! smart contracts.
+- Improve our open source bug-detection tool [Scout](https://coinfabrik.github.io/scout/ ).
+
+## Referral Program (optional) :moneybag:
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result.
+
+During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation.
+
diff --git a/applications/DeepAccountAnalytics-PolkadotDataAlliance.md b/applications/DeepAccountAnalytics-PolkadotDataAlliance.md
index def68a8ed1b..d7704358d97 100644
--- a/applications/DeepAccountAnalytics-PolkadotDataAlliance.md
+++ b/applications/DeepAccountAnalytics-PolkadotDataAlliance.md
@@ -6,7 +6,7 @@
## Abstract :page_facing_up:
-This proposal addresses outstanding [deep account analytics problems for the Web3 Foundation](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/data_analysis_tools.md).
+This proposal addresses outstanding [deep account analytics problems for the Web3 Foundation](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md).
We propse 3-tier solution:
- Tier 1. _raw indexing_: Google BigQuery Public Datasets
@@ -19,7 +19,7 @@ that can support work on all 3 tiers with _child bounties_ for Polkadot Data All
## Project Overview :page_facing_up:
-This proposal is in response to the RFP [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/data_analysis_tools.md)
+This proposal is in response to the RFP [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md)
which seeks to answer deep account analytics questions of:
**Account References**:
diff --git a/applications/Deitos_Network.md b/applications/Deitos_Network.md
new file mode 100644
index 00000000000..9479ad23b38
--- /dev/null
+++ b/applications/Deitos_Network.md
@@ -0,0 +1,306 @@
+# Deitos Network
+
+- **Team Name:** Deitos Network
+- **Payment Method:** USDT (ID 1984) / Polkadot Assethub
+- **Payment Address:** 12DrpztfgAKVubPVv1KcichaW5L4YJutmLGz665xwmbaicrM
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Deitos Network:
+#### An open and decentralized network for Big Data and training models.
+
+Deitos Network aims to be a transparent, open, and decentralized platform dedicated to storage, data processing, modeling, and training.
+
+The network is designed to facilitate collaboration between various infrastructure providers and consumers in need of big data-related services. This encompasses data scientists from startups, academic institutions, and other organizations. Through this engagement, infrastructure providers will receive financial compensation for their services.
+
+The network allows processed and structured data to be utilized by AI and BI systems. This data can produce business analytics reports, predictive algorithms, clean datasets, and training sets, which can be used in different machine learning algorithms, analyses, and trend predictions.
+
+### Why develop blockchain?
+
+We believe that a network like the one we envision can democratize access to structured big data and AI model training. The model we propose is designed for a flexible market fit that can cater to diverse requirements.
+
+Blockchain technology offers a framework to create incentives for a decentralized network. This network can serve a public purpose by providing access to structured or trained data.
+
+### Why Polkadot SDK?
+
+Polkadot SDK is set to be the backbone of the network, orchestrating rewards, data interactions, disputes, consensus, and integrity checks.
+
+With the flexibility of Polkadot SDK, we can design a specific consensus algorithm that considers storage aspects, not just fund staking. On a broader scale, every infrastructure provider will operate a substrate node with an authoring role, and a minimum stake will be necessary to participate in the consensus.
+
+Utilizing Polkadot SDK allows us to implement runtime updates without causing forks or interruptions in the active network.
+
+### Why building Deitos Network?
+
+After thorough evaluation and research, our team identified a specific need and a viable solution. With extensive experience in the big data sector and a deep understanding of Polkadot SDK technology, we are confident in our ability to develop a robust project. We believe that using Polkadot SDK provides a solid foundation, as it is a leading technology for developing blockchains that aim to interoperate.
+
+# Project Details
+
+## Technology Stack
+
+- Polkadot SDK - Blockchain
+- Hadoop - Distributed Storage Management
+- Spark / Hive - Big Data processing tooling
+- Llama v2 - LLM AI training model
+
+### Network actors
+
+#### Infrastructure Providers
+These are entities responsible for providing the necessary infrastructure for all big data-related services. Additionally, they manage the substrate nodes that handle consensus-related operations.
+
+#### Consumers
+As outlined in the project description, the user persona for this network encompasses any individual, entity, or organization requiring storage and computational resources for their data utilization. From the network's standpoint, these consumers are token holders who, alongside infrastructure providers, keep the network operational.
+
+#### Dispute Resolvers Committee
+This group is tasked with resolving any disputes between consumers and infrastructure providers. Membership in this committee isn't static. Individuals must first nominate themselves, after which all token holders can vote within a specified timeframe to determine the nominee's inclusion. This election process is cyclical.
+
+### Network parties interaction flow.
+
+At a high level, when a consumer identifies an infrastructure provider that best suits their needs, they enter into an agreement. This agreement is based on:
+- The volume of storage to be uploaded and analyzed.
+- The computational resources needed for data processing (e.g., vCores, RAM).
+- The duration agreed upon for the above two parameters.
+
+Given these criteria, the consumer compensates the infrastructure provider incrementally, provided the service aligns with the mutual agreement's expectations. To ensure this, the consumer reserves a predetermined percentage of the total agreement value (also decided during the agreement). If there's a breach of contract, a dispute resolution process begins, involving the Dispute Resolvers Committee. They determine if a party has defaulted, be it an infrastructure provider not delivering the agreed resources or a consumer raising unfounded complaints. Upon resolving the dispute, appropriate penalties are enforced, and the dispute resolvers receive compensation for their mediation efforts.
+
+### On-chain reputation system
+After the conclusion of each agreement, participants can review their counterpart. This feedback contributes to an on-chain reputation system, fostering more secure interactions as the network evolves. However, in the event of disputes, neither party can leave feedback. Instead, the dispute's outcome is recorded in their respective profiles.
+
+
+
+## Architecture Overview
+
+
+
+### Network Components
+
+**Substrate Node**: This is responsible for consensus and blockchain-related activities.
+
+**Proxy**: A custom module designed for routing requests and accesses, ensuring that resources from the infrastructure provider align with the security and mechanisms defined by the blockchain.
+
+**HDFS Cluster**: HDFS, or Hadoop Distributed File System, is a distributed file system designed to operate on standard hardware. It's essential for distributed storage that supports extensive data processing.
+
+**YARN**: Handles resource management and job scheduling/monitoring.
+
+**Spark**: Apache Spark is a versatile engine that facilitates data engineering, data science, and machine learning tasks on both single-node machines and clusters.
+
+**Hive**: Apache Hive is a distributed and fault-tolerant data warehouse system, enabling large-scale analytics.
+
+**Llama v2**: The next iteration of our open-source large language model provided by Meta. It's freely available for both research and commercial applications.
+
+**File Uploader**: A custom module designed to process each uploaded file in accordance with consensus requirements.
+
+The architecture landscape of our design primarily consists of two core components: the Polkadot SDK for blockchain-related tasks and a suite of renowned open-source tools for distributed storage. These tools support extensive data processing, such as data structuring, model training, file management, and more.
+
+We've chosen to delegate specific storage and data processing tasks to established open-source software. These tools have been in use for years and are widely recognized within the data science community.
+
+In distributed storage, there are two main conceptual categories: nodes and clusters (networks of nodes that replicate all data across each node).
+
+Each infrastructure provider will maintain a Hadoop cluster with associated services like Spark, Hive, or Llama v2 for data processing and model training. As mentioned earlier, they will also operate a substrate node responsible for block authoring.
+
+### Proxy
+To ensure that the infrastructure provider's resources are used in line with the blockchain's security and mechanisms, we'll develop a proxy system. This system will serve as an interface, validating requests originating from signed transactions. Most of this proxy will depend on the cluster configuration, where system users are created from the user's public key, and authentication is based on account signing. The current authentication system relies on the LDAP protocol, which allows for custom modules to extend the authentication mechanism. The high-level workflow for this custom module is as follows:
+
+1) The user provides their identifier (could be DN or another attribute).
+2) The server generates a challenge and sends it to the user.
+3) The user signs the challenge with their private key and returns the signature.
+4) The server verifies the signature using the stored public key. If valid, the user is authenticated.
+
+No Stored Password: Traditional passwords will not be stored in the LDAP directory in this setup.
+
+### Custom File Uploader (Client Interface)
+After an agreement is reached between an infrastructure provider and a user, the user can begin uploading their files. During this upload, a custom user interface will segment the file into chunks, computing the hash for each segment.
+
+This process will yield something like:
+
+- File ID: 23 / parts: 4 / size: 240 GB.
+- Part ID: 1 / Hash: 662551bf52c62b...
+- Part ID: 2 / Hash: 347858cnqn21dn...
+- Part ID: 3 / Hash: vfnq35gblajfrm...
+- Part ID: 4 / Hash: 3n5jq99vhtb3i9...
+
+Once the file is uploaded to the infrastructure provider, a transaction will be committed, registering this information with an "unverified" status.
+
+From the infrastructure provider's perspective, the same process will occur, ensuring that every hash for each part aligns with the values posted during the user's previous transaction.
+
+### Consensus
+The chain will operate under the BABE and GRANDPA consensus mechanisms. We've chosen the BABE consensus not just for its security advantages over Aura but also because we plan to utilize the VRF (Verifiable Random Function) it generates. This randomness will be instrumental for processes like the Data Integrity Protocol, where a file segment is randomly selected for the cryptographic challenge detailed earlier.
+
+### Data Integrity Protocol
+To ensure that infrastructure providers maintain the agreed-upon storage with users, we will implement a data integrity protocol. This protocol will frequently verify, over a set number of blocks, that each infrastructure provider is storing and preserving the uploaded files.
+
+A pallet responsible for this protocol will execute an off-chain worker (OCW) that randomly selects a file and a part from the infrastructure provider's storage. It will then initiate the hashing calculation for that file/part in the off-chain worker. Once the computation concludes, the hash calculation result should match the value currently stored in the pallet storage. This check will occur as an unsigned transaction from the OCW. If there are 20 infrastructure providers, 20 unsigned transactions will be processed at regular intervals, meaning every a certain number of blocks.
+
+It's worth noting that the randomness value will be sourced from the VRF produced as part of the BABE block production mechanism.
+
+While it may seem evident, it's essential to note that checking the integrity of all files frequently is computationally intensive. By relying on random values that guide the file/part selection, we can probabilistically ensure that the infrastructure provider is storing the files previously uploaded by the user.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- **Hector Bulgarini**: Senior Software Developer and Team Lead
+- **Hernan Borelli**: Product & Project Manager
+- **Ramón Valera**: Data Sciense specialist & Senior Software Developer
+- **Alexander Kalankhodzhaev**: Senior Blockchain and protocol Engineer
+
+### Contact
+
+- **Contact Name**: Hernan Borelli
+- **Contact Email**: hernanbor@gmail.com
+
+
+### Legal Structure
+
+- **Registered Address**: To be provided privately.
+- **Registered Legal Entity**: To be provided privately.
+
+### Team's Experience
+
+**Hector**: With over 15 years in the technology sector, Hector focused on blockchain and Polkadot tech stack evidenced by his work at Parity and the graduation from the first Cambridge cohort of the Polkadot Academy. Hector also have founded and led multiple startups showing a strong entrepreneurial spirit.
+
+**Hernan**: Hernan holds a degree in project management and development. Since 2020, he has been deeply involved in promoting and developing the Polkadot ecosystem in Spanish-speaking countries.
+
+**Ramon**: Ramon is a software engineer with 18 years of experience in a wide range of work areas and applications. His professional career has ranged from the design and development of large-scale enterprise and web applications, to document and database systems management, in addition to application integration and Big Data solutions. In recent years, he has specialized in solving challenges related to Big Data and Application Integration, facing problems of nature and volume of data, as well as performance and efficiency for optimal results.
+
+**Alex**: With a rich experience spanning over 15 years as a software engineer, Alex has worked across various companies and domains. For the past 5 years, he has specialized as a blockchain engineer. Alex is a significant contributor to a substrate node developed in Java, which can be found here: [substrate-client-java](https://github.com/strategyobject/substrate-client-java).
+
+Additionally, he currently maintains GO-LINQ, a language integrated query (LINQ) library for Go. More about it can be found here: [GO-LINQ](https://github.com/ahmetb/go-linq).
+
+
+### Team Code Repos
+
+- [Deitos network](https://github.com/Deitos-Network)
+- Ramon: https://github.com/rvalera
+- Alex: https://github.com/kalaninja
+- Hector: https://github.com/hbulgarini
+
+### Team LinkedIn Profiles
+
+**Linkedin profiles**
+- Hector: https://www.linkedin.com/in/hector-esteban-bulgarini-0791147
+- Ramon: https://www.linkedin.com/in/ramonvalera
+- Hernan: https://www.linkedin.com/in/hernan-borelli-62296261
+- Alex: https://www.linkedin.com/in/kalaninja/
+
+## Ecosystem Fit
+
+The Polkadot ecosystem is known for its integration of a myriad of projects, each offering distinct functionalities. These projects often interoperate with one another and frequently rely on external data to achieve their objectives. Our primary aim is to supply blockchain-validated, processed big data for various systems and applications that necessitate this kind of information.
+
+**Target Audience**
+
+While structured big data caters to a diverse range of users and applications, Deitos Network is specifically tailored to develop a system and user experience (UX) optimized for Artificial Intelligence (AI) and Business Intelligence (BI) applications.
+
+**Problem Statement**
+
+The digital realm is witnessing an unprecedented surge in data, leading to challenges in hosting, structuring, analyzing, and processing this vast amount of information. Various entities, from businesses and governments to scientists and other professionals, are in dire need of this data for a plethora of applications. However, they often grapple with limitations in accessing and utilizing it effectively. The exponential growth of big data far outpaces our current capacity to process it, resulting in a vast reservoir of unstructured data that remains untapped for many potential applications. The intricate process of structuring and analyzing this data demands immense computational power, further constraining its effective use.
+
+On the flip side, fostering a diverse ecosystem of big data storage, management, and processing providers can offer users solutions that are more attuned to their specific needs and requirements.
+
+**Similar Projects in the Ecosystem**
+
+In the realm of data storage and processing, two notable projects are making strides in the development of decentralized networks:
+
+- **Subspace**: This project is geared towards addressing the blockchain trilemma. Its primary feature revolves around the development of a Secure & Sustainable Consensus, specifically the Proof-of-Archival-Storage (PoAS) consensus. Among its other salient features, it emphasizes full decentralization and composite scaling.
+
+- **Cess**: Positioned as a Large-Scale Decentralized Cloud Data Solution, CESS's Decentralized Cloud Network is fine-tuned for processing high-frequency dynamic data. It facilitates real-time data sharing while ensuring the protection of users' data ownership, privacy, and assets.
+
+- **Arweave**: A decentralized storage network designed to offer permanent data storage.
+
+While Deitos Network shares similarities with platforms such as Crust, Arweave, and IPFS, Deitos primary focus is distinct. The network emphasizes the processing, structuring, and utilization of data. The direction leans more towards Big Data and AI functionalities than acting as a descentralized storage service.
+
+- **DecentralML**: A Polkadot protocol for decentralised federated machine learning and collective governance.
+
+Based on the grant information from [DecentralML](https://github.com/w3f/Grants-Program/blob/master/applications/decentral_ml.md), it appears there are parallels in terms of decentralizing machine learning model training, where rewards are based on data model training contributions and parameter adjustments by governance.
+
+Deitos approach, however, adopts a distinct architecture and game theory strategy. It focuses on infrastructure providers offering private services, competing to deliver optimal solutions to consumers. In future developments, these providers may also engage in maintaining and utilizing a shared public dataset, rewarded for hosting this data and processing consumer requests. (Section added from application's feedback).
+
+## Relevant prior work and research on the topic
+
+Some of the following topics/reads were analyzed and processed:
+
+- [BlockHDFS: Blockchain-integrated Hadoop distributed file system for secure provenance traceability](https://www.sciencedirect.com/science/article/pii/S2096720921000270)
+- Trusted Execution environment
+- Proof of Space
+- Shamir’s Secret Sharing
+- Distributed Key Generation
+- Subspace
+
+## Development Status :open_book:
+
+Our team has been diligently exploring various cryptographic primitives and experimenting with different substrate configurations to progress towards a Proof of Concept (PoC).
+These can be found in the Github organization.
+
+## Development Roadmap :nut_and_bolt:
+
+### Grant Scope
+
+This grant is specifically earmarked for the foundational development of the network. Once the foundational elements, such as the substrate node and runtime, are established, the grant's focus will shift towards the development of the Infrastructure Provider Management module, Proxy,the Data Integrity Protocol and the disputes mechanism. This can also be perceived as the mechanisms for authentication, data upload, and integrity verification.
+
+Elements related to data consumption or querying, as well as the inclusion of other computational resources like vCPUs and RAM within the agreement, fall outside the purview of this grant. These aspects are slated for consideration in future development phases. Additionally, there are certain security implications associated with the Data Integrity Protocol and data consumption. Addressing these will necessitate advanced privacy measures, potentially involving zero-knowledge proofs.
+
+
+### Overview
+
+- **Total Estimated Duration:** 12 weeks (3 months).
+- **Full-Time Equivalent (FTE):** 3 FTE
+- **Total Costs:** 30.000 USD
+
+### Milestone 1 — Initial setup and infrastructure provider pallet.
+
+- **Estimated duration:** 6 weeks
+- **FTE:** 3
+- **Costs:** 15,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | The project will utilize the GNU General Public License v3 (GPLv3) license. |
+| **0b.** | Documentation | All the functionalities developed in this milestone will contain the corresponding inline code documentation. In addition, all the configuration for the services included in the Infrastructure Provider will be documented. |
+| **0c.** | Testing and Testing Guide | 1) All the different pallets and functionalities will contain their own unit testing contained in the `test.rs` files including the inline documentation for each test purpose. 2) Comprehensive testing guide for interacting with all the functionalities from the `pallet-deitos`. 3) User guide to start the Docker file provided in the delivery item **0d.**|
+| **0d.** | Docker file | 1) Provision of a Docker file encapsulating all essential services. 2) Streamlined deployment of services: Hadoop, Spark, Hive, YARN, Llama v2, and the substrate node. 3) A docker-compose file to simplify onboarding and integration for providers. |
+| 1. | Substrate Node with BABE consensus | 1) Reconfiguration of the node to employ the BABE consensus protocol in place of the Aura consensus. 2) Integration of the respective VRF setup for BABE consensus. 3) Proper configurations on the node side like integrating the `BabeBlockImport`, initiating BABE workers, and setting inherents from `sp_consensus_babe` on the node service.rs file beyond just embedding the pallet-babe in the runtime|
+| 2. | Pallet Deitos foundation (pallet-deitos) | 1) Introduction of foundational elements of the pallet, incorporating storage items for cataloging Provider data, the specifics of agreements between Providers and Consumers, the reputation system and the data integrity protocol. 2) Framework scaffolding for future enhancements. 3) Groundwork for the data integrity protocol to be executed by this pallet's off-chain worker. |
+| 3. | Registration of Infrastructure Provider (pallet-deitos) | 1) Mechanism for infrastructure provider registration within the pallet-deitos. 2) Requirement of reserving a certain amount of funds. 3) Groundwork for attestation process initiation for new entrants. This will be completed in the next milestone with the data integrity protocol. |
+| 4. | Agreements Module (pallet-deitos) | 1) Functionality to define agreements between users and infrastructure providers. 2) Outline of storage quotas and its duration based on block by block reward dynamics. 3) Introduction of pertinent extrinsics, storage components, and events for agreements. 4) Mechanism where the consumer reserves a value based on the agreement's terms, leveraging either the ReservedCurrency trait from pallet-balances or the MutateHold trait from Fungibles depending of the pallet-balances migration status. |
+| 5. | Agreements termination and on-chain reputation (pallet-deitos) | 1) Termination agreement procedure where consumer's data and corresponding resources get free from the infrastructure provider. 2) Data Integrity protocol clean up. 3) On chain reputation module based on feedback from the other party. |
+
+### Milestone 2 — Proxy, file uploader and data integrity protocol.
+
+- **Estimated duration:** 6 weeks
+- **FTE:** 3
+- **Costs:** 15,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | The project will utilize the GNU General Public License v3 (GPLv3) license. |
+| **0b.** | Documentation | Building upon the documentation provided in the first milestone, this milestone will introduce a new set of user guidelines. As the grant approaches its conclusion and all implementation details are settled, we will provide thorough protocol documentation. |
+| **0c.** | Testing and Testing Guide | 1) All the different pallets and functionalities will contain their own unit testing contained in the `test.rs` files including the inline documentation for each test purpose. 2) This milestone will deliver the necessary tools to establish a local testing environment, allowing for comprehensive testing of all functionalities. |
+| **0d.** | Docker | As we plan to deliver the software to infrastructures providers (IP) in docker images, all the protocol services will be configured and delivered in the IP Docker image. |
+| **0e.** | Articles | For the grant conclusion we will create two Medium articles: The first one will be a project introduction targeting a more general and wide audience. Some of the content will include: 1) Deitos Network introduction and network offering, 2) Roles and protocol functioning, 3) Design decisions. On the second article, we will delve into more technical information where the development aspect of this grant will be discussed. The audience for this second article will be more technical and the following items will be discussed: 1) Architecture in depths, 2) Substrate pallets descriptions, 3) Internal functioning of each module. |
+| 1. | Proxy Development | 1) Complete development and deployment of the described proxy ensuring interaction between infrastructure providers, consumers and the substrate node. 2) Mechanism to reserve resources on the infrastructure provider for a consumer upon agreement commitment. 3) A system focused on storage where user segmentation is achieved through dynamic users generated on Hadoop. 4) Authentication derived from a signed transaction initiated by the pallet-deitos pallet. 5) Development of a module to validate consumer signatures and commit actions upon successful verification, ensuring no traditional passwords are stored in the system. |
+| 2. | File Uploads (Client Interface) | 1) Delivery of a client interface to facilitate file content splitting and hash calculation. 2) Creation of a generic algorithm to uniformly split files and calculate segment hashes. 3) Mechanism for producing and publishing signed transactions reflecting the computed results.|
+| 3. | File Upload Verification (Provider Side) | 1) Using the previously generic algorithm to uniformly split files and calculate segment hashes for each file or part upon receiving the consumer's signed transaction. Files are marked as 'verified' post successful hash validation. 3) Constant monitoring of blocks to detect unverified files, triggering an OCW for hash verification based on consumer transactions. |
+| 4. | Data Integrity Protocol | 1) Comprehensive development and deployment of the Data Integrity Protocol. 2) Utilizing BABE-generated randomness to select files/parts, directing infrastructure providers to create and validate respective hashes. 3) In case of hash mismatches during the data integrity protocol, a system to penalize the provider by reducing their staked amount. |
+
+## Mid-Term Plans
+
+### High-Level Overview roadmap.
+
+1) Development of the storage layer and data model foundations, which is the current grant's focus.
+2) Addition of the execution aspects for agreements and the dispute resolution mechanism.
+3) Implementation of security measures such as infrastructure provider attestation to ensure execution integrity and reliability.
+
+- Further development of the network's roadmap, which includes:
+ - Deliver a on-chain dispute resolving module in case of disagreements between consumers and infrastructure providers (Stage 2).
+ - Introducing data consumption processes, such as querying or interacting with the model (Stage 2).
+ - Implementing security mechanisms around the infrastructure provider to ensure the environment remains free from dishonest manipulations (Stage 3).
+ - Incorporating privacy primitives, like ZK proofs, to bolster data integrity and query processes (Stage 3).
+- The aforementioned roadmap can be viewed as the essential MVP (Minimum Viable Product) for launching a test network, facilitating initial iterations.
+- As we transition to a production phase, our plan is to secure core time, positioning us to join the Polkadot network as a parachain.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?**
+Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc.
+
+The team has a longstanding engagement with the ecosystem, making us well-acquainted with Web3 grants.
diff --git a/applications/FuzzLand.md b/applications/FuzzLand.md
index 9a712bc9370..2898f55bbab 100644
--- a/applications/FuzzLand.md
+++ b/applications/FuzzLand.md
@@ -273,7 +273,7 @@ Downstream DeFis, including insurance, using the auditing intermediate informati
Other projects can reuse the components of FuzzLand platforms. For example, the optimistic rollups pallet can be used by Layer 2 solutions. Collaborative manual auditing projects can also use the audit pallet or our chain by replacing the rollups pallet with consensus pallets.
-[Decentralized Security Marketplace](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/decentralized-security-marketplace.md) is a related RFP. [QRUCIAL DAO](https://github.com/w3f/Grants-Program/pull/989) is a related project in Substrate ecosystem. QRUCIAL DAO and FuzzLand both reach consensus about the auditing result. The fundamental differences are:
+[Decentralized Security Marketplace](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/decentralized-security-marketplace.md) is a related RFP. [QRUCIAL DAO](https://github.com/w3f/Grants-Program/pull/989) is a related project in Substrate ecosystem. QRUCIAL DAO and FuzzLand both reach consensus about the auditing result. The fundamental differences are:
* FuzzLand harnesses the computation power of the crowd to perform compute-intensive dynamic program analysis, resulting in fast and highly accurate auditing. Yet, QRUCIAL DAO's analysis is performed by rerunning a same set of fast static analysis tools on multiple nodes, of which the requirement of multiple nodes is solely for reaching consensus.
* We support all LLVM targets, including Substrate pallet, ink!, Solidity, Move, Rust, C/C++, etc. projects while QRUCIAL DAO is tailored for smart contract auditing.
* We use optimistic rollups to efficiently reach consensus while QRUCIAL DAO uses the governance pallet.
diff --git a/applications/Grant_management_webapp.md b/applications/Grant_management_webapp.md
index 4765962aba4..1218c5736c7 100644
--- a/applications/Grant_management_webapp.md
+++ b/applications/Grant_management_webapp.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-This application is in response to the open RFP: https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/grant_management_webapp.md
+This application is in response to the open RFP: https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/grant_management_webapp.md
### Overview
diff --git a/applications/Hyperdot.md b/applications/Hyperdot.md
index 3abc771e9c3..bb9f7be6619 100644
--- a/applications/Hyperdot.md
+++ b/applications/Hyperdot.md
@@ -6,7 +6,7 @@
## Project Overview 📄
-This is a response for the [Analytics Website/Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/analysis-website-and-data-platform.md) RFP.
+This is a response for the [Analytics Website/Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/analysis-website-and-data-platform.md) RFP.
### Overview
diff --git a/applications/ISO-8583-implementation.md b/applications/ISO-8583-implementation.md
index 793db9fe492..e15db0e8d5b 100644
--- a/applications/ISO-8583-implementation.md
+++ b/applications/ISO-8583-implementation.md
@@ -3,8 +3,9 @@
- **Team Name:** Dastanbek Samatov
- **Payment Address:** 0xc42D0562BB4e53f5e9D888df35e1B91eA0f19cC3 (USDC)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1809#issuecomment-1866632852)
-This application is in response to the [ISO-8583 RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/ISO_8583.md).
+This application is in response to the [ISO-8583 RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_8583.md).
### Overview
@@ -111,7 +112,7 @@ Please also provide the GitHub accounts of all team members. If they contain no
## Development Status :open_book:
-This application is in response to the [ISO-8583 RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/ISO_8583.md).
+This application is in response to the [ISO-8583 RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_8583.md).
The implementation is inspired from the previous [research](https://github.com/adit313/ISO8583-Blockchain-Integration-Plan) project for this RFP.
diff --git a/applications/ISO20022.md b/applications/ISO20022.md
index fe5926a0662..50e1bb7d190 100644
--- a/applications/ISO20022.md
+++ b/applications/ISO20022.md
@@ -7,7 +7,7 @@
## Project Overview
-Response to [RFP 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/ISO_20022.md)
+Response to [RFP 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_20022.md)
Cross-border payment example as proof of concepts, leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/v3/concepts/off-chain-features/) that show the advantages of using [ISO20022](https://www.iso20022.org/) together with Substrate.
diff --git a/applications/Interstellar-network2.md b/applications/Interstellar-network2.md
index fb4363d91e2..61234c20887 100644
--- a/applications/Interstellar-network2.md
+++ b/applications/Interstellar-network2.md
@@ -1,4 +1,4 @@
-# Interstellar - Wallet Phase 2
+# Interstellar - Wallet Phase 2 (amended)
- **Team Name:** Interstellar
@@ -170,9 +170,8 @@ We are now multiple security and fintech entrepreneurs, security researchers, pa
| ------: | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **0a.** | License | APACHE 2 |
| **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 our stack and send test transactions, which will show how the new functionality works. |
-| **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. | | | |
-| 1. | Garble Circuit pallet update | We will rewrite the garbled circuit evaluation scheme to target at least **60 fps** through parralelization, caching and likely with an efficient [1.permutation-based garbling scheme: see 4.5](https://www.cs.fsu.edu/~tvhoang/thesis.pdf) optimized for performance or a [2.new garbling scheme](https://www.esat.kuleuven.be/cosic/publications/article-3351.pdf) that could potentially require lower computation cost per gate|
+| **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.| | | |
+| 1. | Garble Circuit pallet update | We will rewrite the garbled circuit evaluation scheme to target at least **60 fps** through parralelization, caching and likely with an efficient [1.permutation-based garbling scheme: see 4.5](https://www.cs.fsu.edu/~tvhoang/thesis.pdf) optimized for performance or a [2.new garbling scheme](https://www.esat.kuleuven.be/cosic/publications/article-3351.pdf) that could potentially require lower computation cost per gate|
@@ -189,10 +188,18 @@ We are now multiple security and fintech entrepreneurs, security researchers, pa
| **0a.** | License | APACHE 2 |
| **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 our stack and send test transactions, which will show how the new functionality works. |
| **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. | | | |
+ | | | |
| 1. | Display Circuit update | We will modify the current display circuit to enable a more comfortable user experience by decreasing the cognitive load needed for the user to read the screen. - likely by adding specific sub-circuits to manage a set of probabilities of displaying segments for each frame, then fine tuned segments ON/OFF per frame to improve readbility
| 2. | Light security screen | We will provide a less secure but very comfortable to read secure screen version using fading with less blinking (link) - this non-screenshot proof version will be used later with our adaptive security framework |
+**Additional information (reason for amendment):**
+
+As we prioritize the user experience and aim to showcase the FPS improvement and overall viusal improvement for the user compared to the previous milestone, there is no need for a Docker here. Instead, we provide an offline demo app to simplify the evaluation.
+
+However, if you'd like to test the full pipeline for this milestone, we can provide you with both a Docker and an online version of the app and the related demo tutorial.
+
+
+
diff --git a/applications/JsonRpsee-socks5-proxy.md b/applications/JsonRpsee-socks5-proxy.md
new file mode 100644
index 00000000000..106abe8df8d
--- /dev/null
+++ b/applications/JsonRpsee-socks5-proxy.md
@@ -0,0 +1,99 @@
+# JsonRpsee socks5 proxy
+
+* **Team Name:** [gmajor](https://github.com/gmajor-encrypt)
+* **Payment Address:** 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F(USDC)
+* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/2068#issuecomment-1840145149)
+
+## Project Overview :page_facing_up:
+
+RFPs [https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/jsonrpsee-proxy-support.md](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/jsonrpsee-proxy-support.md)
+
+### Overview
+
+This proposal is to develop a JsonRpsee socks5 middleware proxy.
+
+### Project Details
+
+This proposal is to develop a JsonRpsee [socks5](https://datatracker.ietf.org/doc/html/rfc1928) middleware proxy.
+
+
+### Ecosystem Fit
+
+- Where and how does your project fit into the ecosystem?
+
+ This project is a middleware that can be used to proxy connections using a socks5 proxy. It can be used in any application that uses jsonrpsee as a client.
+
+- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase,
+ yourself)?
+
+ jsonrpsee client developers
+
+- What need(s) does your project meet?
+
+ Enhance the JsonRpsee package and add support for socks5 proxy
+
+- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
+
+ Nothing
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+* gmajor
+
+### Contact
+
+* **Contact Name:** gmajor
+* **Contact Email:** gmajorencrypt@gmail.com
+* **Website:**
+
+### Legal Structure
+
+individual
+
+### Team's experience
+
+I have many years of PHP development experience and nearly five years of blockchain development experience, familiar
+with PHP, GOLANG, PYTHON, Nodejs, Rust
+
+### Team Code Repos
+
+- https://github.com/gmajor-encrypt/php-scale-codec
+- https://github.com/gmajor-encrypt/php-substrate-api
+- https://github.com/gmajor-encrypt/scale-codec-comparator
+- https://github.com/gmajor-encrypt/sr25519-bindings
+- https://github.com/gmajor-encrypt/xcm-tools
+
+## Development Status :open_book:
+
+Not yet
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+* **Total Estimated Duration:** 1 months
+* **Total Costs:** 9000 USDC
+
+### Milestone 1
+
+
+* **Estimated duration:** 4 week
+* **FTE:** 1
+* **Costs:** 9000 USDC
+
+| Number | Deliverable | Specification |
+|-------:|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| 0a. | License | MIT or Apache 2.0 |
+| 0b. | Documentation | Simple documentation on how to use and how to test |
+| 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. |
+| 1. | Socks5 middleware support | Enable a jsonrpsee client to proxy connections using a socks5 proxy |
+| 2. | Example | I will now provide an example to demonstrate the usage of this socks 5 middleware. |
+| 3. | Pull request | Create pull request merge into [jsonrpsee](https://github.com/paritytech/jsonrpsee) |
+
+
+## Future Plans
+
+If there are any problems with this feature, I will still maintain it.
diff --git a/applications/Lastic.md b/applications/Lastic.md
new file mode 100644
index 00000000000..24e097c00a4
--- /dev/null
+++ b/applications/Lastic.md
@@ -0,0 +1,255 @@
+# Lastic
+
+- **Team Name:** Lastic
+- **Payment Address:** bc1q0d6pkmsvncshyeqvzzlcfjc7lkf4fuku7nsen7 (BTC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+
+> :exclamation: *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:
+
+### Overview
+
+ - Lastic is a pioneering blockspace marketplace developed on Polkadot.
+ - Our mission with Lastic is to democratize Polkadot blockspace, offering cost-effective and accessible solutions. Our marketplace facilitates the purchase and sale of 'Coretime,' aiming to normalize pricing, present user-centric payment options, and possibly launch subscription or futures offerings. With Lastic, deploying or extending a Polkadot project becomes seamless.
+ - Our faith in the coretime model underscores Polkadot’s leadership in modular blockspace. To create a universal blockspace marketplace, we believe Polkadot’s advanced technology is unparalleled.
+
+### Project Details
+The complete vision of Lastic is a broad and intensive endeavor that involves building on technology that is not yet complete nor wholly available. Our journey in this space reveals the risks of investing heavily in transient technologies. In alignment with the Web3 Foundation grant's objectives, our focus remains on forward-thinking strategies that offer tangible value. **Thus, our proposal emphasizes developing a user interface (UI) tailored for the Coretime Parachain.**
+
+This grant's goal is to create a UI within the limitations of `the broker pallet` being still in development and not deployed as a testnet yet. Concurrently, we will devise a **static mockup**, with simulated data, illustrating user interactions with the future coretime chain.
+
+Grant Objectives:
+ - Construct a UI mockup dedicated for future interactivity with the Coretime chain.
+ - Envision limited interactivity based on features presently available in the `broker pallet`. This is contingent on the running the pallet as a substrate node locally.
+
+Exclusions for this grant:
+ - Real-time data derived via indexers on cores acquired historically.
+ - Interaction beyond the limited functionality within the scope of this grant.
+ - Functionalities allowing Polkadot users to alter cores, such as fragmentation.
+ - The capability for buying or selling coretime on secondary markets, which remains Lastic's long-term vision.
+
+### Ecosystem Fit
+
+- **Role in the Ecosystem**: Lastic seamlessly integrates within the Polkadot ecosystem, offering users an intuitive interface to assess the real-time status of coretime. This includes insights into available cores, owned cores, sales prospects for coretime, task allocations, newly created regions, regions within the instantaneous coretime pool, and transactions related to instantaneous coretime.
+
+- **Target Audience**: Our primary user base encompasses:
+ - Parachain teams looking for blockspace to expand or optimize their projects.
+ - dApp developers aiming to ensure smooth and scalable operations.
+ - Smart contract developers seeking efficient blockspace management.
+ - Collators and validators striving for enhanced network optimization.
+ - Coretime providers looking for a transparent space to offer their services.
+ - Polkadot analysts and analytics providers in need of real-time coretime data.
+ - MEV actors aiming to maximize their strategies.
+ - DOT holders keen on understanding and optimizing their blockspace assets.
+
+- **Addressing the Needs**: The Lastic UI is meticulously designed to cater to users desiring a simplified yet comprehensive overview of the coretime landscape on Polkadot. In the broader vision, along with providing a better user experience for those looking to buy Bulk and Instantanious Coretime, Lastic plans to pioneer a robust secondary marketplace for Polkadot's blockspace. This platform will facilitate the buying and selling of blockspace, supporting projects that need expansion or those that have excess blockspace to offer.
+
+- **Comparison to Existing Solutions**: When evaluating the existing landscape within the Substrate/Polkadot/Kusama ecosystem, we found no projects that are currently in development with Lastic's vision or offerings, making our initiative unique and essential.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Phil Lucsok (aka Asynchronous Phil)
+- Aurora Makovac (aka Aurora Poppyseed)
+
+### Contact
+
+- **Contact Name:** Phil Lucsok, Aurora Poppyseed
+- **Contact Email:** plucsok@gmail.coml, aurora.makovac@gmail.com
+- **Website:** [lastic.xyz](https://www.lastic.xyz/)
+
+### Legal Structure
+
+- **Registered Address:** Private
+- **Registered Legal Entity:** In progress
+
+### Team's experience
+
+#### **Phil Lucsok**:
+Phil began his career in web3 as a marketing and communications manager for a Bitcoin startup in Berlin in 2013 called [BitcoinsBerlin](https://web.archive.org/web/20220707055043/https://bitcoinsberlin.com/). There, he created marketing campaigns for multiple products including:
+- [All4BTC](https://all4btc.com/) - a one-stop shop for purchasing anything on Amazon or eBay with bitcoin
+- Bills4BTC (later [Bitwala](https://bitwala.com/), Nuri) - a SEPA-compliant payment method for holders of Bitcoin for regular payments
+- e4BTC - an electronics shop supporting purchases in Bitcoin
+
+After this, he worked for 3.5 years at [ResearchGate](https://www.researchgate.net/), a web2 social media platform for scientific researchers, where he learned skills in Product Management, Product Analytics, UX development and copywriting and design, and industry-standard growth practices.
+
+In late 2017, Phil joined Parity Technologies to lead technical communications on Ethereum and Polkadot. There he worked closely with developers to create promotional content for open-source products including Parity Ethereum, Parity Signer, Polkadot.js. It was between 2018 and 2020 where he represented Parity in Ethereum governance to help recover the stuck funds from the November 2017 multisig hack.
+
+He led the communications team for the first two years, growing the team from 1 to 12, where they created and executed the launch strategies for Polkadot, Kusama and Substrate. After that he joined the Ecosystem Success team to work with parachain teams to improve their communications and act as a liason between Substrate Builders Program teams and Parity.
+
+Phil currently works as a freelancer but is focused on leading [Missing Link](https://www.missing-link.io/)'s marketing, communications and governance strategies. He is also an active participant in Polkadot governance discussions on the Kusamarian and in ChaosDAO.
+
+*Note: Phil Lucsok has not previously applied for a grant at the Web3 Foundation.*
+
+#### **Aurora Poppyseed**:
+Aurora's journey in the technological sphere stands out for her innovative approach and unwavering determination. With a foundation in Physics and Electrical Engineering, she transitioned into roles as varied as a Solutions Architect, focusing on electronics and low-level programming, to a Frontend Developer with a commitment to clean code and scalable frontend architectures.
+
+At [**Instrumentation Technologies**](https://www.i-tech.si/) in Nova Gorica, Slovenia, she led the design of intuitive GUIs for advanced measurement devices in particle accelerators and streamlined future development with a standardized Vue CLI-based web GUI framework. Her contribution as a Frontend Developer at [**Block Analitica**](https://blockanalitica.com/) involved engineering the frontend framework for the [**Ajna project**](https://www.ajna.finance/) initiated by the **MakerDAO team**, ensuring clean coding practices and an organized project structure for future open-source contributions.
+
+Aurora attended and graduated from the [**Polkadot Blockchain Academy**](https://www.polkadot.network/development/academy/) at UC Berkeley (engineering track), learning about the fundamentals of blockchain from leaders in this domain. Further enhancing her mark in the blockchain domain, Aurora offered her expertise to [**KodaDot**](https://kodadot.xyz/), a prominent multi-chain NFT marketplace, developing developer documentation and crafting both technical and non-technical articles to amplify the platform's presence.
+
+In the realm of community engagement and organization, Aurora co-organized the [**Polkadot Bled mini-conference**](https://www.meetup.com/subwork/events/292274713) and more recently, orchestrated a breakfast as a side event at sub0 aimed at [**women in Polkadot** in collaboration with **H.E.R. Dao**](https://lu.ma/dzuqx5nw). This gathering aimed to empower and bring together women leaders and enthusiasts in the Polkadot ecosystem. Furthermore, she's a staunch supporter of [**SubWork**](https://subwork.xyz/), a tech-centric coworking hub in the scenic Bled region and one of the pioneer **Polkadot hubs**.
+
+Now a freelance blockchain developer, Aurora champions women's representation in Polkadot and ardently supports community-driven blockchain initiatives.
+
+*Note: Aurora Poppyseed has not previously applied for a grant at the Web3 Foundation.*
+
+---
+
+### Team's Repository & Online Presence
+
+**Organization's GitHub Page**:
+- [LasticXYZ Official Page](https://github.com/LasticXYZ)
+
+**Primary Repository for Grant Submission**:
+- [Lastic UI Repository](https://github.com/LasticXYZ/lasticUI)
+
+**Team Member GitHub Profiles**:
+- [Phillux's GitHub](https://github.com/phillux)
+- [PoppyseedDev's GitHub](https://github.com/poppyseedDev)
+
+**LinkedIn Profiles**:
+- [Philip Lucsok](https://www.linkedin.com/in/philiplucsok)
+- [Aurora Makovac](https://www.linkedin.com/in/auroramakovac)
+
+## Development Status & Progress
+
+The main hub of our grant-related development is the [LasticUI Repository](https://github.com/LasticXYZ/LasticUI). The groundwork of this repository stems from the [substrate frontend template](https://github.com/substrate-developer-hub/substrate-front-end-template), providing us with a robust starter code.
+
+We're progressing by configuring our frontend development environment locally, leveraging the Substrate framework, and establishing a direct connection with it. Detailed setup and operational instructions can be accessed in the repository's [README.md](https://github.com/LasticXYZ/LasticUI/blob/main/README.md).
+
+Our secondary [Lastic Repository](https://github.com/LasticXYZ/Lastic) is currently private but will soon transition to public access. This space captures our internal deliberations framed as issues, preliminary whitepaper drafts, and an essential frontend for our main website, [lastic.xyz](https://www.lastic.xyz/), augmented with pertinent links.
+
+**Insightful Blogs**:
+1. [The Genesis of a Coretime Marketplace for Polkadot](https://medium.com/lastic-marketplace/the-genesis-of-lastic-a-coretime-marketplace-for-polkadot-9dc851fa365f)
+2. [Polkadot 2.0 - A new era of decentralization](https://medium.com/lastic-marketplace/polkadot-2-0-a-new-era-of-decentralization-d5626a6e63e5)
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Estimated duration:** 1 month
+- **FTE:** 2
+- **Total Costs:** 10000 USD
+
+### Milestone 1 - Creating a Frontend with basic functionality for the coretime chain
+
+- **Estimated duration:** 1 month
+- **FTE:** 2
+- **Costs:** 10000 USD
+
+> :exclamation: **The default deliverables 0a-0d below are mandatory for all milestones**, and deliverable 0e at least for the last one.
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | Licensed under GPLv3 |
+| **0b.** | Documentation | Comprehensive documentation will include inline code comments and a detailed wiki. The wiki will clarify core terms such as “coretime” and “assignments” for user understanding. This will be a one-stop resource for insights into coretime's intricacies and functionalities. |
+| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive UI testing framework to ensure functionality and robustness. UI Testing involves making sure all functionality works as intended, and from different browsers, OSs and platforms. On MacOS, Linux, and Windows, we will test browsers including, but not limited to: Chrome, Firefox, Safari, Edge, Brave and Safari for iOS and Chrome on Android. We will test for consistency across platforms and browsers, ensuring all navigational elements work, all graphics are rendered correctly, all data is updated in a timely fashion, for mobile responsiveness, and that there are no unintended results. |
+| **0d.** | Error logging | In the event of an error, we will ensure the UI writes the error details to an event viewer or log file for later review. |
+| **0e.** | Article Publishing | **Five articles** will be published covering topics from Polkadot 2.0 insights to the Lastic long-term vision. 1. [The Genesis of a Coretime Marketplace for Polkadot](https://medium.com/lastic-marketplace/the-genesis-of-lastic-a-coretime-marketplace-for-polkadot-9dc851fa365f) 2. [Polkadot 2.0 - A new era of decentralization](https://medium.com/lastic-marketplace/polkadot-2-0-a-new-era-of-decentralization-d5626a6e63e5) 3) How Agile Coretime works and what it provides 4.) Further Coretime developments based on Gavin's talk at Protocol Berg (Corejam, Coreplay) 5. The Lastic Roadmap, including our future long-term vision of Lastic |
+| 1. | Whitepaper creation | Comprehensive Lastic whitepaper creation. |
+| 2a. | User Flow Diagram Design | A user-centric flow diagram will be designed to showcase the interaction journey on the platform. This design will be in line with the principles highlighted in the RFC for coretime chain and broker pallet. It will primarily cover the instantaneous coretime sales and primary market sales, leaving out the secondary market. The finalized user flow diagram will be accessible via a link in the LasticUI repository's README.md file. |
+| 2b. | UI Figma Design | We will craft a Figma-based UI design for the coretime chain, with the focus on instantaneous coretime sales and primary market sales (excluding the secondary market). This task will be undertaken without the aid of a professional designer. Preliminary mockups for this stage have been initiated and further details can be gleaned from the expansion of section 3.b. The complete design will be shared through a link in the LasticUI repository's README.md file. |
+| 3a. | Frontend Development - Broker Pallet Integration | This phase will integrate basic interactions available in the `broker pallet` into the frontend. Detailed insights into the interactable features can be found in the expanded section of 3.a. Key deliverables will encompass the inclusion of all listed UI extrinsic functions, relevant UI constants, and selected UI storage queries limited to the fuctionality that can be implemented locally. More details are available in the expansion of 3.a section. |
+| 3b. | Mockup-based Frontend Development | We will bring to life the mockups for both Instantaneous Coretime sales and the primary market for Bulk Coretime sales as visualized in the UI designs under section 2.b. These mockups will due to limitations of time restirictions only feature "fake data" and not the actual data from the coretime chain. To get an in-depth view of these, refer to the expanded details in section 3.b. |
+
+---
+
+### Expansion of 3.a - Basic Interaction Creation
+
+#### UI extrinsic functions:
+
+*Note: Functions with system admin privilege are not included here and will not be included in the UI.*
+
+| Function Name | Description |
+|---------------|-------------|
+| renew | Renew Bulk Coretime in the ongoing Sale or its prior Interlude Period. |
+| transfer | Transfer a Bulk Coretime Region to a new owner. |
+| partition | Split a Bulk Coretime Region into two non-overlapping Regions at a particular time into the region. |
+| interlace | Split a Bulk Coretime Region into two wholly-overlapping Regions with complementary interlace masks which together make up the original Region's interlace mask. |
+| assign | Assign a Bulk Coretime Region to a task. |
+| pool | Place a Bulk Coretime Region into the Instantaneous Coretime Pool. |
+| claim_revenue | Claim the revenue owed from inclusion in the Instantaneous Coretime Pool. |
+| purchase_credit | Purchase credit for use in the Instantaneous Coretime Pool. |
+| drop_region | Drop an expired Region from the chain. |
+| drop_contribution | Drop an expired Instantaneous Pool Contribution record from the chain. |
+| drop_history | Drop an expired Instantaneous Pool History record from the chain. |
+| drop_renewal | Drop an expired Allowed Renewal record from the chain. |
+| request_core_count | Request a change to the number of cores available for scheduling work. |
+
+#### UI constants:
+
+| Constant Name | Description |
+|---------------|-------------|
+| PalletId | Identifier from which the internal Pot is generated. |
+| TimeslicePeriod | Number of Relay-chain blocks per timeslice. |
+| MaxLeasedCores | Maximum number of legacy leases. |
+| MaxReservedCores | Maximum number of system cores. |
+
+#### UI storage to query:
+_Note: Not all storage to query listed here will be implented in the scope of this grant._
+
+| Storage Item | Description |
+|--------------|-------------|
+| Configuration | The current configuration of this pallet. |
+| Reservations | The Polkadot Core reservations (generally tasked with the maintenance of System Chains). |
+| Leases | The Polkadot Core legacy leases. |
+| Status | The current status of miscellaneous subsystems of this pallet. |
+| SaleInfo | The details of the current sale, including its properties and status. |
+| AllowedRenewals | Records of allowed renewals. |
+| Regions | The current (unassigned) Regions. |
+| Workplan | The work we plan on having each core do at a particular time in the future. |
+| Workload | The current workload of each core. This gets updated with workplan as timeslices pass. |
+| InstaPoolContribution | Record of a single contribution to the Instantaneous Coretime Pool. |
+| InstaPoolIo | Record of Coretime entering or leaving the Instantaneous Coretime Pool. |
+| InstaPoolHistory | InstaPool rewards for each Timeslice and the number of core parts which contributed. |
+
+
+### Expansion of 3.b - Basic Interaction Creation
+_Note: All designs featured here are just quick design mockups and will be prone to change during the duration of this grant._
+
+This mockup/UI design features the design of the page Instantanious Coretime sales.
+
+
+This mockup/UI design features the design of the page primary market for the Bulk sales.
+
+
+**** We will create a frontend allowing users to see the current state of Coretime on Polkadot, including, but not limited to: Number of cores available, Number of cores assigned, Number of legacy cores assigned, Number of blocks in the Instantaneous Pool, Number of Cores parititioned, etc. Note: this will be made using dummy data. |
+
+
+## Future Plans
+
+- Lastic aims to become a secondary marketplace for blockspace on Polkadot using its new Agile Coretime model
+- We intend to first build out a UI for the community to gather, assess, and analyze the state of Coretime including its availability and sales
+- After Agile Coretime is enabled on Rococo, we will plug in our UI so that it can become useful to the community right away
+- Lastic will support Rococo, Kusama and Polkadot
+- Users will be able to purchase coretime in the 'default' methods of bulk and instantaneous via Lastic
+- Users will be able to use Lastic as a way to view, paritition, resell, purchase, and trade coretime in various ways
+- The long-term vision for Lastic is that it will be the one place for ANY user to buy and sell blockspace on Polkadot, regardless of the state machine or smart contract or application they have.
+- Lastic aims to support features for the upcoming roadmap laid out in the RFCs, for example Coreplay and Corejam
+
+### On the Horizon: Frontend Development with Blockchain Integration:
+
+Initiation Timeline: Post the release of W3F's branch on the Rococo testnet, followed by data availability for real-time functionality testing. Estimated commencement: 4 months post-Rococo testnet launch, with the mainnet integration slated 3-6 months thereafter.
+
+Developmental Milestones:
+
+ - Integration with Subquery to facilitate efficient storage querying.
+ - Design and implement a dynamic pricing simulation tool.
+ - Facilitate smooth synchronization with testnet, subsequently followed by devnet.
+ - Establish a robust secondary marketplace, ensuring it undergoes rigorous testing phases.
+ - Pave the way for feature enablement on major platforms such as Polkadot and Kusama's mainnets.
+ - Dedicated efforts towards crafting a user-centric interface for the secondary marketplace. For a preliminary glimpse of our vision, refer to the mockup showcased below:
+
+
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?**
+
+- Phil's experience working at Parity informed him of the Web3 Grants program.
+- Aurora has learned about the Web3 Grants program during her time working at KodaDot.
+
+Additional information:
+- We have received no financial contributions to Lastic, nor have applied for any other grants
diff --git a/applications/LiisaPortfolioTracker.md b/applications/LiisaPortfolioTracker.md
index da742528247..b89ef9e36c5 100644
--- a/applications/LiisaPortfolioTracker.md
+++ b/applications/LiisaPortfolioTracker.md
@@ -1,11 +1,11 @@
# Polkadot NFT Portfolio Tracker by Liisa - MVP
- **Team Name:** Liisa
-- **Payment Address:** 0x096a685Bfd75c3998CFC4c70177e17ee6b582B0A
+- **Payment Address:** Fiat 04.01.2024, 11:55 PM GMT
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
-## Project Overview :page_facing_up:
+## Project Overview :page_facing_up:
Liisa operates as a multi-chain NFT data analytics platform, engineered to empower collectors and investors in making proficient, data-driven decisions.
@@ -20,7 +20,7 @@ The portfolio tracker is designed to accommodate the diverse needs of a broad us
### Architecture
-
+
### Technologies
@@ -49,11 +49,11 @@ React.js, often simply called React, is an open-source JavaScript library develo
The project aims to create a system to extract and process event data and metadata related to NFTs within the Polkadot ecosystem. The focus is on building flexible and modular data ingestion mechanisms to accommodate different APIs with minimal code changes, using Node.js components for reusability and scalability.
-To expedite development, the team will initially integrate with the Subsquid API, which is well-documented, robust and opensource, and provides extensive data for selected protocols like Astar (ERC721, ERC1155, PSP34, PSP37), Basilisk (Uniques pallet), Efinity (ERC-721, ERC-1155), Moonbeam (ERC-721, ERC-1155), Unique Network (Native NFTs), Moonriver (ERC-721, ERC-1155) and Moonsama (ERC-721, ERC-1155). This initial integration will serve two main purposes: to quickly progress towards a working MVP and to serve as a practical example for future developers looking to extend the system with other data sources in the long term.
+To expedite development, the team will initially integrate with the Subsquid API, which is well-documented, robust and opensource, and provides extensive data for selected protocols like Astar (ERC721, ERC1155, PSP34, PSP37), Basilisk (Uniques pallet), Efinity (ERC-721, ERC-1155), Moonbeam (ERC-721, ERC-1155) and Moonriver (ERC-721, ERC-1155). This initial integration will serve two main purposes: to quickly progress towards a working MVP and to serve as a practical example for future developers looking to extend the system with other data sources in the long term.
#### 2) Data Enrichment
-Our backend serves as a vital nexus between supported blockchain protocols and valuable metrics we generate for user wallets and NFT collections. It involves three key activities: crafting and executing API queries, initiating timed triggers, and developing computational algorithms for metrics computation. We create and execute precise API queries to extract event data from Subsquid for protocols such as Astar (ERC721, ERC1155, PSP34, PSP37), Basilisk (Uniques pallet), Efinity (ERC-721, ERC-1155), Moonbeam (ERC-721, ERC-1155), Unique Network (Native NFTs), Moonriver (ERC-721, ERC-1155) and Moonsama (ERC-721, ERC-1155). This enables the continuous refresh of our system with recent blockchain events pertinent to the monitored NFT collections and user wallets.
+Our backend serves as a vital nexus between supported blockchain protocols and valuable metrics we generate for user wallets and NFT collections. It involves three key activities: crafting and executing API queries, initiating timed triggers, and developing computational algorithms for metrics computation. We create and execute precise API queries to extract event data from Subsquid for protocols such as Astar (ERC721, ERC1155, PSP34, PSP37), Basilisk (Uniques pallet), Efinity (ERC-721, ERC-1155), Moonbeam (ERC-721, ERC-1155), and Moonriver (ERC-721, ERC-1155). This enables the continuous refresh of our system with recent blockchain events pertinent to the monitored NFT collections and user wallets.
Our backend employs timed triggers to initiate queries to Subsquid at predefined intervals, ensuring we maintain an up-to-date snapshot of relevant blockchain events. Incoming event data, acquired via timed or event-driven triggers, is processed using specially designed computational algorithms. These algorithms generate key performance indicators (KPIs) and metrics for both user wallets and NFT collections, capturing the most essential insights. The calculated metrics are persistently stored in our database, ensuring their continuous availability for subsequent retrieval, analysis, and the provision of comprehensive insights into users' wallets and NFT collections.
@@ -61,7 +61,7 @@ All the code for data enrichment will be opensource so that more developers in t
#### 3) Database
-We will be utilizing PostgreSQL as our database management system to store and manage all data. PostgreSQL is an advanced open-source relational database management system that offers a broad range of powerful features. As our choice of infrastructure provider, we will be deploying PostgreSQL on Amazon Web Services (AWS).
+We will be utilizing PostgreSQL as our database management system to store and manage all data. PostgreSQL is an advanced open-source relational database management system that offers a broad range of powerful features. As our choice of infrastructure provider, we will be deploying PostgreSQL on Google Cloud Platform (GCP).
#### 4) Frontend
@@ -164,13 +164,13 @@ In a proactive endeavor to understand and address the data-related challenges of
### Overview
-- **Total Estimated Duration:** 3 months
+- **Total Estimated Duration:** 5 months
- **Full-Time Equivalent (FTE):** 2.25
- **Total Costs:** 30,000 USDC
### Milestone 1 — On-chain data collection, indexing and calculations
-- **Estimated duration:** 1.5 months
+- **Estimated duration:** 2.5 months
- **FTE:** 2.5
- **Costs:** 17,000 USDC
@@ -180,7 +180,7 @@ In a proactive endeavor to understand and address the data-related challenges of
| 0b. | Documentation | Documentation includes Inline Code Documentation, Configuration Documentation, Readme file. Documentation on the modular design of Subsquid API calls is included. |
| 0c. | Testing Guide | The code will have unit-test coverage (min. 50%) to ensure functionality and robustness. In the guide, we will describe how to run these tests |
| 0d. | Docker | Provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
-| 1a. | Modular Subsquid API calls | Design and implement API queries to extract event data from the Subsquid API for the supported protocols and the respective token standards and/or pallets: Astar (ERC721, ERC1155, PSP34, PSP37), Basilisk (Uniques pallet), Efinity (ERC-721, ERC-1155), Moonbeam (ERC-721, ERC-1155), Unique Network (Native NFTs), Moonriver (ERC-721, ERC-1155) and Moonsama (ERC-721, ERC-1155). The design will be modular to allow easy replacement with different APIs. This will be developed using Node.js. |
+| 1a. | Modular Subsquid API calls | Design and implement API queries to extract event data from the Subsquid API for the supported protocols and the respective token standards and/or pallets: Astar (ERC721, ERC1155, PSP34, PSP37), Basilisk (Uniques pallet), Efinity (ERC-721, ERC-1155), Moonbeam (ERC-721, ERC-1155) and Moonriver (ERC-721, ERC-1155). The design will be modular to allow easy replacement with different APIs. This will be developed using Node.js. |
| 1b. | Timed-Triggers | Establish timed triggers to initiate queries to the Subsquid API at predetermined intervals, subsequently refreshing the associated events database with the most recent data. This will be developed using Node.js on the main code and will use cronjobs on the cloud to set the triggers. |
| 1c. | User-initiated Triggers | Implement event-driven triggers that are activated upon user interactions with the application, specifically upon insertion of a wallet address. This will initiate Subsquid API queries and subsequently update the associated events database with the retrieved data. This will be developed using Node.js. |
| 2a. | Open-sourced Computational algorithms | Design and implement computational algorithms that, upon activation of either event-driven or timed triggers and the consequent receipt of new event data, will produce key performance indicators (KPIs) and metrics for both user wallets and NFT collections. The calculated metrics will subsequently be stored persistently in the database for subsequent analysis and retrieval. This code will be open-sourced and developed using Node.js. |
@@ -190,7 +190,7 @@ In a proactive endeavor to understand and address the data-related challenges of
### Milestone 2 — Portfolio tracker front-end implementation
-- **Estimated Duration:** 1.5 month
+- **Estimated Duration:** 2.5 month
- **FTE:** 2.0
- **Costs:** 13,000 USD
diff --git a/applications/MeProtocol.md b/applications/MeProtocol.md
index d171ade6ce0..64802904bea 100644
--- a/applications/MeProtocol.md
+++ b/applications/MeProtocol.md
@@ -1,7 +1,7 @@
# Me Protocol
- **Team Name:** My AI
-- **Payment Address:** Ethereum: 0xB35da2E7380a2580Acdc0ca5DEa9e2B152155e84 (USDC)
+- **Payment Address:** POLKADOT: 14K4XzpMBxGp8NiCKMWAwzjFMLcAKjakXooqHtVEC6WoaeTq (DOT)
- **Level:** 2
@@ -125,7 +125,7 @@ A similar project on the DEFI side is Stellaswap (https://stellaswap.com/) and o
- Paul Oamen (CTO)
- Pius Onobhayedo
- John Chimaobi
- - Samuel Anthony
+ - Ayomide Adebara
- Boluwatife Oguntoyinbo
- Nwele Uchenna
@@ -168,7 +168,7 @@ GitHub accounts of team members
- https://github.com/codemobii
- https://github.com/piosystems
- https://github.com/Teepheh-Git
-- https://github.com/thellecodes
+- https://github.com/Adebara123
### Team LinkedIn Profiles (if available)
@@ -181,8 +181,8 @@ GitHub accounts of team members
### Overview
-- **Total Estimated Duration:** 4 months
-- **Full-Time Equivalent (FTE):** 2400 hrs
+- **Total Estimated Duration:** 5 months
+- **Full-Time Equivalent (FTE):** 2600 hrs
- **Total Costs:** 29600 USD
### Milestone 1 — Implement the Core Parts of the Protocol
@@ -208,8 +208,8 @@ GitHub accounts of team members
### Milestone 2 — Adding the Protocol Peheripherals and Kickstarting the Frontend and Backend services
-- **Estimated Duration:** 1 month
-- **FTE:** 800hrs (5 persons)
+- **Estimated Duration:** 2 months
+- **FTE:** 900hrs (3 persons)
- **Costs:** 8,550 USD
| Number | Deliverable | Specification |
@@ -231,8 +231,8 @@ GitHub accounts of team members
### Milestone 3 — Rounding Up with the APP MVP and Integrating the Protocol with the APP
-- **Estimated Duration:** 1 month
-- **FTE:** 800hrs (5 persons)
+- **Estimated Duration:** 2 months
+- **FTE:** 900hrs (3 persons)
- **Costs:** 8,550 USD
| Number | Deliverable | Specification |
diff --git a/applications/Melodot.md b/applications/Melodot.md
index 56a692562d6..94403276d42 100644
--- a/applications/Melodot.md
+++ b/applications/Melodot.md
@@ -173,11 +173,11 @@ ZeroDAO previously developed the Ourspace project, which is a reputation system
| **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 spin up a client, connect to the client management application and data through a browser, and create a local development chain. |
| **0c.** | Testing and Testing Guide | Higher-level integration tests and unit tests for all modules. In the guide, we will describe how to run these tests. |
-| **0d.** | Docker | We will provide Dockerfiles to start multiple nodes with different roles, create a local test network, and run all integration tests. |
-| 1. | Substrate pallet: excutive_das | Depends on the `frame-executive` pallet, extending the DAS-related scheduling and data structures. The main functionalities include scheduling data availability throughout the lifecycle of blocks, which involves the block proposer constructing data, erasure coding, KZG commitments, and generating extended block headers. Validators verify if they are generated correctly. |
-| 2. | Substrate pallet: system_das | Depends on the `frame-system` pallet, extending the DAS-related actual operations. The system_das is a specific implementation of the executive_das functionality, which primarily includes: 1) Extracting availability data 2)Applying erasure coding 3) Generating KZG commitments and proofs 4)Generating extended block headers. Validators: 1) Verify the correctness of the generated KZG commitments 2) Validate the proofs by conducting non-interactive challenge 3) Verify the correct generation of data availability block headers. |
-| 3. | Substrate pallet: melo_store | Pallet for managing apps and submitting data. The main functions include dispatchable functions for application registration, permission management, and uploading availability data. It also encompasses an interface for availability management, allowing validators to modify data availability based on availability sampling. |
-| 4. | melodot-client | Fully implemented data availability layer node client. |
+| **0d.** | Docker | We will provide Dockerfiles to start nodes, create a local test network, and run all integration tests. |
+| 1. | Substrate pallet: excutive_das | Modify the existing `frame-executive` pallet to support custom headers while ensuring all original tests continue to function. |
+| 2. | Substrate pallet: system_das | Extend the `frame-system` pallet to support the creation of extended headers. |
+| 3. | Substrate pallet: melo_store | A core pallet for handling data availability. Main features include: 1) Registering applications. 2) Allowing users to submit data metadata. 3) Validators accessing off-chain storage via OCW and reporting unavailable data. 4) Interface for creating extended block header. |
+| 4. | melodot-client | A substrate client containing a complete data availability layer. The DAS core features include: 1) Accepting user-submitted blob_tx, verifying if the data is correctly encoded, submitting the transaction, and publishing the data to a peer-to-peer network 2) Validators retrieving data transactions from the transaction pool and attempting to fetch the data from DHT to save locally. |
### Milestone 3 — Sampling
diff --git a/applications/Plutonication.md b/applications/Plutonication.md
new file mode 100644
index 00000000000..6023a0cbad6
--- /dev/null
+++ b/applications/Plutonication.md
@@ -0,0 +1,498 @@
+# Plutonication
+
+- **Team Name:** Plutonication
+- **Payment Address:** 1WmPE1X9Ykpb7QcVamPtUSRjEZy2GMDeTm5N72DyXYiqMCo (USDT)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Please provide the following:
+
+#### If the name of your project is not descriptive, a tag line (one sentence summary).
+
+- Communications protocol that enables seamless interactions between dApps and wallets across all platforms.
+
+#### A brief description of your project.
+
+- Plutonication allows users to connect PlutoWallet to other dApps seamlessly on any platforms, accross multiple codebases.
+DApp just generates a QR code and once it is scanned in the wallet, they will pair and the wallet will be able to receive transaction requests from the dApp. It works on the same principle as WalletConnect protocol.
+
+- You can see a short (90 sec) demo here: https://youtu.be/hw2B8-sBc9A?si=O8MiWa0Wq1jxfZdr
+
+#### An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.
+
+- Currently, the only way to connect your mobile wallet to other dApps is to use Wallet connect protocol, or a very clunky Polkadot Vault (Parity signer).
+
+- We think, we will be good competitors to WalletConnect and that we will do will better than them!
+
+- Our Plutonication Extension already works with most of the web dApps as supposed to WalletConnect, which is implemented into only a handful of dApps.
+
+- WalletConnect is also only available in javascript and we would like to expand it further to other programming languages.
+
+- C# is a very popular programming language for games and there have not been much focus on it in the Polkadot Ecosystem appart from Ajuna Network and their excellent Substrate.NetApi. We are dirrectly communicating with Ajuna developers to help better coordinate the Substrate.NetApi development and Plutonication, so that their are dirrectly compatible with each other.
+
+#### An indication of why your team is interested in creating this project.
+
+- We have been very pationate about Plutonication since the beginning. We have noticed the lack of WalletConnect protocol before it was available.
+
+- We have been working on Plutonication in our free time to prove the concepts are possible.
+
+- We have also landed a second place at Polkadot Global Series: Europe edition 2023 hackathon in Web3 and Tooling category.
+
+### Project Details
+
+We expect the teams to already have a solid idea about your project's expected final state. Therefore, we ask the teams to submit (where relevant):
+
+#### Data models / API specifications of the core functionality
+
+Native Plutonication:
+
+```mermaid
+flowchart LR
+
+subgraph Cloud
+S[Plutonication Websocket Server]
+end
+
+subgraph Any device
+D[dApp using Plutonication]
+end
+
+subgraph Phone
+W["Mobile wallet
+ Private key always stays here"]
+end
+
+S -- Receive signed payload --> D
+D -- Send extrinsic payload --> S
+
+S -- Receive extrinsic payload --> W
+W -- Send signed payload --> S
+
+D -. Scan QR code for establishing connection .-> W;
+```
+
+Plutonication on existing polkadot.js apps:
+```mermaid
+flowchart LR
+
+subgraph Cloud
+S[Plutonication Websocket Server]
+end
+
+subgraph Web
+D[dApp using Polkadot.js] ~~~ E[Plutonication Extension]
+E -. Connection via Polkadot.js extension .- D
+end
+
+subgraph Phone
+W["Mobile wallet
+ Private key always stays here"]
+end
+
+S -- Receive signed payload --> E
+E -- Send extrinsic payload --> S
+
+S -- Receive extrinsic payload --> W
+W -- Send signed payload --> S
+
+E -. Scan QR code for establishing connection .-> W;
+```
+
+#### An overview of the technology stack to be used
+
+1) Plutonication server (Python): Flask, Flask-SocketIO
+2) Mobile Wallet: https://github.com/rostislavLitovkin/plutowallet
+3) Plutonication Native (C#): SocketIOClient, Substrate.NetApi
+4) Plutonication Native (TS): socket.io-client, Polkadot.js
+5) Plutonication Extension: socket.io-client, Polkadot.js extension
+
+#### Documentation of core components, protocols, architecture, etc. to be deployed
+
+##### Plutonication Server
+- Used for reliable establishing of connection.
+- Passes payloads between Wallets and dApps.
+
+##### Mobile Wallet
+- Has access to the private key
+- signs the payloads and sends them back to the dApp.
+- Never exposes the private key
+
+##### dApp
+- needs to have access to either: Plutonication Native / Plutonication Extension
+
+##### Plutonication Native
+- A simple package that allows the dApp get connected with the Mobile Wallet.
+- Connects the dApp with the Plutonication server.
+- Helps to generate a QR code for the Wallet to establish the connection.
+
+##### Plutonication Extension
+- a polkadot.js extension that works with any existing dApp that supports polkadot.js extension.
+- Connects the dApp with the Plutonication server.
+- Generate a QR code for the Wallet to establish the connection.
+
+#### PoC/MVP or other relevant prior work or research on the topic
+- Second place at Polkadot Global Series: Europe edition 2023 hackathon in Web3 and Tooling category.
+- https://github.com/cisar2218/Plutonication
+- Plutonication is integrated to: https://github.com/rostislavLitovkin/plutowallet
+- https://github.com/rostislavLitovkin/plutonicationextension
+
+#### What your project is _not_ or will _not_ provide or implement
+
+- Any improvements to PlutoWallet appart from the things needed for Plutonication to work in the PlutoWallet.
+
+- Although it is planned support Kotlin and Swift programming languages as well, it is not part of this grant proposal.
+
+- We are certainly willing to make PRs to other popular dApps to utilise Plutonication, it is also not part of this grant proposal. We would be willing to do a follow-up grant or get a treasury funding to make the PRs.
+
+### 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?
+
+- Our project is comparable to WalletConnect, which was also our inspiration.
+
+##### [WalletConnect](https://walletconnect.com/)
+- When we started making our first prototypes in February, WalletConnect was not available in the Polkadot Ecosystem yet.
+Even thought they have taken a lot of time and had a lot more experience then us, they were unable to make quick and elegant deliveries.
+WalletConnect still is not supported by most of the dApps. We think we can do better. Actually, we already did.
+
+- We made a Plutonication Extension, which already allows you to interact with existing dApps, even though they have not implemented the Plutonication standard directly. This can be a perfect middle ground during the transition of popularizing the Plutonication. Even if the user wanted to use a new niche dApp, they can do so with Plutonication.
+
+- Wallet connect is also only supported in javascript. We want to make Plutonication available in more languages, including a very popular C# language, which is mostly used for game development. We will make web3 gaming possible on game consoles, thanks to the Plutonication.
+
+- WalletConnect's server solution (also known as WalletConnect cloud) is not opensourced. We want to be open to everybody and fully opensourced.
+
+##### [SubConnect](https://github.com/Koniverse/SubConnect)
+- This is a great aggregation of wallets. This certainly improves the UX and simplifies the development for developers. However, it is not trying to do the same thing as Plutonication. Plutonication tries to achieve connection between 2 different platforms (like mobile wallet on Android and dApp on web on Windows).
+
+- It may be certainly a good idea to talk to SubWallet to implement Plutonication into the SubConnect solution.
+
+##### [Tesseract](https://github.com/tesseract-one/Tesseract.rs)
+
+- Tesseract is a great solution for connecting a wallet and a dApp together on a single device. However, Plutonication allows wallets and dApps to be connected across different devices.
+
+##### [@talismn/connect](https://github.com/TalismanSociety/talisman-connect)
+
+- This is similar to SubConnect. Once again, we try to solve a completely different problem.
+
+#### Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
+
+- dApps developers - To integrate the Plutonication in their dApps. We will ensure that the developers will receive a good documentation.
+
+- Wallet developers - We are welcoming other wallets to use the Plutonication. We would like to help them make this possible.
+
+- Users - In the end, it will be mainly used by mobile focused users. They will be able to interact with web3 apps on unusual platforms, like game consoles, smartwatches ...
+
+#### What need(s) does your project meet?
+
+- You are unable securely interact with dApps on gaming consoles, smartwatches and other unusual platforms. Without Plutonication, you would have to expose your private key, which is very unsafe.
+
+- You can also interact with existing web dApps with your mobile wallet. Again, you do not need to expose your private key to multiple places (in this case browser extension wallet), which would be very unsafe.
+
+#### Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
+
+- Yes, WalletConnect.
+
+#### If so, how is your project different?
+
+- We support more programming languages. We also have a browser extension that enables Plutonication on existing dApps.
+
+- WalletConnect also mainly focuses on Ethereum ecosystem. We are focusing only on Polkadot.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+#### Name of team leader:
+
+Rostislav Litovkin
+
+#### Names of team members:
+
+Valentina Gómez
+
+Dušan Jánsky
+
+### Contact
+
+- **Contact Name:** Rostislav Litovkin
+- **Contact Email:** rostislavlitovkin@gmail.com
+- **Website:** https://github.com/cisar2218/Plutonication
+
+### Legal Structure
+
+- **Registered Address:** Píškova 1946/12, 155 00, Prague, Czech republic
+- **Registered Legal Entity:** None
+
+### Team's experience
+
+#### [Rostislav Litovkin](http://rostislavlitovkin.pythonanywhere.com/aboutme)
+- Alumnus at Polkadot Blockchain Academy 2023 in Berkeley
+- Experienced .net MAUI developer, e.g.:
+ - [Galaxy Logic Game](https://github.com/RostislavLitovkin/galaxylogicgamemaui) (successful game for watches and mobiles, 50k+ downloads)
+- Frontend developer at [Calamar explorer](https://calamar.app/)
+- Successful student at Polkadot DevCamp #2
+- Successful student at [Solana Summer School](https://ackeeblockchain.com/school-of-solana)
+- Polkadot Global Series 2023 (Europe) - second place
+- Audience choice prize at EthPrague 2023
+
+#### Valentina Gómez
+- Alumnus at Polkadot Blockchain Academy 2023 - Berkeley.
+- Full stack web developer in TeamClass.
+- Financial Engineer
+
+#### Dušan Jánsky
+- Alumnus at Polkadot Blockchain Academy 2023 in Berkeley
+- Student at Faculty of Electrical Engineering Czech Technical University in Prague - Opens Informatics (specialization in computer games and computer graphics)
+- Fullstack developer at [Universal Scientific Technologies](https://www.ust.cz/)
+- Polkadot Global Series 2023 (Europe) - second place
+
+#### If anyone on your team has applied for a grant at the Web3 Foundation previously, please list the name of the project and legal entity here.
+
+Rostislav Litovkin helped with **Calamar.app - TopMonks s.r.o**
+
+### Team Code Repos
+
+- https://github.com/ThunderFly-aerospace/thumby
+- https://github.com/topmonks/calamar
+- https://github.com/RostislavLitovkin/GalaxyLogicGameMAUI
+- https://github.com/RostislavLitovkin/Uniquery.Net
+
+#### 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/cisar2218
+- https://github.com/rostislavlitovkin
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/dusan-jansky-6aab69239/
+- https://www.linkedin.com/in/valentinaga1/
+
+## Development Status :open_book:
+
+If you've already started implementing your project or it is part of a larger repository, please provide a link and a description of the code here. In any case, please provide some documentation on the research and other work you have conducted before applying. This could be:
+
+- The idea was already tested by WalletConnect. Now, we are expanding it further in the Polkadot ecosystem.
+
+- We have already made working MVPs which can be found here:
+
+ - https://github.com/cisar2218/Plutonication
+
+ - https://github.com/rostislavLitovkin/plutowallet
+
+ - https://github.com/rostislavLitovkin/plutonicationextension
+
+## Development Roadmap :nut_and_bolt:
+
+This section should break the development roadmap down into milestones and deliverables. To assist you in defining it, we have created a document with examples for some grant categories [here](../docs/Support%20Docs/grant_guidelines_per_category.md). Since these will be part of the agreement, it helps to describe _the functionality we should expect in as much detail as possible_, plus how we can verify and test that functionality. Whenever milestones are delivered, we refer to this document to ensure that everything has been delivered as expected.
+
+Below we provide an **example roadmap**. In the descriptions, it should be clear how your project is related to Substrate, Kusama or Polkadot. We _recommend_ that teams structure their roadmap as 1 milestone ≈ 1 month.
+
+> :exclamation: If any of your deliverables is based on somebody else's work, make sure you work and publish _under the terms of the license_ of the respective project and that you **highlight this fact in your milestone documentation** and in the source code if applicable! **Projects that submit other people's work without proper attribution will be immediately terminated.**
+
+### Overview
+
+- **Total Estimated Duration:** 2 months
+- **Full-Time Equivalent (FTE):** 0.83 FTE
+- **Total Costs:** 25,000 USD
+
+### Milestone 1 Plutonication Server (Python: Flask)
+
+- **Estimated Duration:** 1 month
+- **FTE:** 0.33
+- **Costs:** 5,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | MIT |
+| **0b.** | Documentation | We will provide both **in code documentation for individual methods**. We will also provide a tutorial on how to run the Plutonication Server locally and in cloud. |
+| **0c.** | Testing and Testing Guide | ~~All of the functions will be end-to-end tested with a sample dApp written in typescript (with Plutonication and Polkadot.js api) and a sample Wallet (PlutoWallet)~~ Unit tests for all of the functions |
+| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone and for running the server in production. |
+| 1. | PlutonicationServerFlask | A Python server with Flask and Flask-SocketIO used for establishing a stable websocket connection between the dApp and Wallet. Use of server is crucial for reliable establishing of connection. |
+| 1a. | create_room | dApp creates room |
+| 1b. | pubkey | Sends an account address (SS58 encoded) from wallet to dApp |
+| 1c. | sign_payload | dApp requests an extrinsic payload signature |
+| 1d. | sign_raw | dApp requests a raw message signature |
+| 1e. | payload_signature | wallet provides an extrinsic payload signature |
+| 1f. | raw_signature | wallet provides a raw message signature |
+| 2. | database requirements | none |
+
+### Milestone 2 Plutonication Typescript version
+
+- **Estimated Duration:** 1 month
+- **FTE:** 0.5
+- **Costs:** 7500 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | MIT |
+| **0b.** | Documentation | We will provide both **in code documentation for individual methods** and a **tutorial** explaining how to integrate Plutonication into a javascript/typescript dApp. |
+| **0c.** | Testing and Testing Guide | All of the functions will be end-to-end tested with a sample dApp written in typescript (with Plutonication and Polkadot.js api) and a sample Wallet (PlutoWallet) |
+| **0d.** | Docker | We will provide a Dockerfile for a sample dApp that can be used to test all the functionality delivered with this milestone. |
+| 1. | PlutonicationDAppClient | This would be a series of methods tailored for use with dApps. We will make sure that it is compatible with polkadot.js api |
+| 1a. | Initialize(AccessCredentials ac) -> void | Method used for initializing the PlutonicationDAppClient |
+| 1b. | ReceiveAddress() -> Address | Handles the receiving of SS58 encoded address |
+| 1c. | SendPayloadAsync(Payload payload) -> void | Method used for requesting an extrinsic payload sign |
+| 1d. | SendRawAsync(Bytes rawMessage) -> void | Method used for requesting a raw message sign |
+| 2. | PlutonicationWalletClient | This would be a series of methods tailored for use with wallets. |
+| 2a. | SendAddress(Address address) -> void | Sends the SS58 encoded address of the account in the wallet |
+| 2b. | SendSignedPayloadAsync(Payload signedPayload) -> void | Method used for sending a signed extrinsic payload back to the dApp. The signed extrinsic payload will then be added to the extrinsic and submitted to chain. |
+| 2c. | SendSignedRawAsync(bytes signedRaw) -> void | Method used for sending a signed raw message back to the dApp. |
+| 3. | QR code pop-up | We will provide a function that would embed an HTML qr code popup into a dApp. The QR code is used for establishing a connection. |
+| 4. | NPM package | We will provide an NPM package, which is commonly used it javascript/typescript development. |
+| 5. | Sample dApp | We will make a sample typescript console dApp (with Plutonication and Polkadot.js api) published to a public github repo. |
+
+### Milestone 3 Plutonication C# version
+
+- **Estimated duration:** 1 month
+- **FTE:** 0.5
+- **Costs:** 7500 USD
+
+> :exclamation: **The default deliverables 0a-0d below are mandatory for all milestones**, and deliverable 0e at least for the last one.
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | MIT |
+| **0b.** | Documentation | We will provide both **in code documentation for individual methods** and a **tutorial** explaining how to integrate Plutonication into a c# dApp. |
+| **0c.** | Testing and Testing Guide | All of the functions will be end-to-end tested with a sample dApp written in c# (with Plutonication and Substrate.NetApi) and a sample Wallet (PlutoWallet) |
+| **0d.** | Docker | We will provide a Dockerfile for a sample dApp that can be used to test all the functionality delivered with this milestone. |
+| 1. | PlutonicationDAppClient | This would be a series of methods tailored for use with dApps. We will make sure that it is compatible with Substrate.NetApi |
+| 1a. | Initialize(AccessCredentials ac) -> void | Method used for initializing the PlutonicationDAppClient |
+| 1b. | ReceiveAddress() -> Address | Handles the receiving of SS58 encoded address |
+| 1c. | SendPayloadAsync(Payload payload) -> void | Method used for requesting an extrinsic payload sign |
+| 1d. | SendRawAsync(bytes rawMessage) -> void | Method used for requesting a raw message sign |
+| 2. | PlutonicationWalletClient | This would be a series of methods tailored for use with wallets. |
+| 2a. | SendAddress() -> Address | Sends the SS58 encoded address of the account in the wallet |
+| 2b. | SendSignedPayloadAsync(Payload payload) -> void | Method used for sending a signed extrinsic payload back to the dApp. The signed extrinsic payload will then be added to the extrinsic and submitted to chain. |
+| 2c. | SendSignedRawAsync(bytes signedRaw) -> void | Method used for sending a signed raw message back to the dApp. |
+| 3. | NuGet package | We will provide a NuGet package, which is commonly used it c# development. It is comparable to NPM packages in Javascript world. |
+| 4. | Sample dApp | We will make a sample C# console dApp (with Plutonication and Substrate.NetApi) published to a public github repo. |
+| 5. | Testing moved from milestone 1 | All of the functions will be end-to-end tested with a sample dApp written in typescript (with Plutonication and Polkadot.js api) and a sample Wallet (PlutoWallet) |
+
+### Milestone 4 Plutonication extension
+
+- **Estimated Duration:** 1 month
+- **FTE:** 0.33
+- **Costs:** 5,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | MIT |
+| **0b.** | Documentation | We will provide **inline documentation of the code**. |
+| **0c.** | Testing and Testing Guide | All of the functions will be end-to-end tested with a sample dApp (https://polkadot.js.org/apps/) and a sample Wallet (PlutoWallet) |
+| **0d.** | Docker | We will not provide a docker file |
+| **0e.** | Article | We will publish an article that explains what was done as part of the grant. We will mention how Plutonication is ground-breaking and can be used by anyone. |
+| 1. | Plutonication Extension | This is a [polkadot.js extension](https://github.com/polkadot-js/extension) compatible browser extension for Plutonication. |
+| 1a. | Inject(..) | Injects the browser extension into the polkadot.js dApp. |
+| 1b. | ReceiveAddress(..) | Handles the receiving of SS58 encoded address |
+| 1c. | SendPayloadAsync(..) | Method used for requesting an extrinsic payload sign |
+| 1d. | ReceiveSignedPayloadAsync(..) | Method used for receiving a signed extrinsic payload data. This signed extrinsic payload will then be added to the extrinsic and submitted to chain. (Done automatically by polkadot.js) |
+| 1e. | SendRawAsync(..) | Method used for requesting a raw message sign |
+| 1f. | ReceiveSignedRawAsync(..) | Method used for receiving a signed raw message. |
+| 2. | Chrome browser extension | Released to Chrome Web Store |
+
+## Future Plans
+
+Please include here
+
+#### how you intend to use, enhance, promote and support your project in the short term, and
+
+- Once all of these 4 milestones are completed, we will have a solid ground to start integrating Plutonication to other dApps.
+
+#### the team's long-term plans and intentions in relation to it.
+
+- Our goal would be to create multiple PRs to already popular dApps to utilise Plutonication. At that point, other wallet companies will have a solid motivation to start integrating Plutonication into their wallets too.
+
+- Further plans are to combine Plutonication with PlutoWallet custom layouts (find more in PlutoWallet readme: https://github.com/RostislavLitovkin/PlutoWallet) and make onboarding of new users easier.
+
+- The endgoal would be to become a defaultly used solution for wallet injection.
+
+## Referral Program (optional) :moneybag:
+
+You can find more information about the program [here](../README.md#moneybag-referral-program).
+- **Referrer:** https://github.com/topmonks
+- **Payment Address:** 32NoFbB4x8bZ7YNvjra1DUYcje2B2XQwP3 (BTC)
+
+- They are a grants alumni.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** - personal recommendation
+
+Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:
+
+#### Work you have already done.
+
+- https://github.com/cisar2218/Plutonication
+
+- https://github.com/rostislavLitovkin/plutonicationextension
+
+- https://github.com/rostislavLitovkin/plutowallet
+
+#### If there are any other teams who have already contributed (financially) to the project.
+
+- Nobody has financially supported the project.
+
+#### Previous grants you may have applied for.
+
+- None yet.
+
+#### Why are you focusing on C#? Do you have any relation to Ajuna?
+
+- I was a c# developer and I still like it to this day. It is probably the best option for game development and in my opinion also the best way to develop mobile applications.
+Originally, I wanted to create a mobile dApp with c# frontend, so I did my research and that is how I discovered Ajuna and their [Substrate.NetApi](https://github.com/SubstrateGaming/Substrate.NET.API).
+It was an excellent tool to get started and without it, I would have probably gave up and moved on. I still noticed that few of the important features were missing, like these:
+ - how to securely connect a foreign wallet to a c# dApp.
+ - how to efficiently query NFT data.
+ - how to elegantly interact with smart contracts (namely ink! contracts) from c#.
+
+- So I started addressing them one by one.
+ - First is Plutonication.
+ - Second is https://github.com/rostislavlitovkin/uniquery.net (this one is already production ready)
+ - Third was just brainstormed during PBA. It might be my next project in the future.
+
+- Regarding Ajuna, I am currently in a very close relationship with them. We discuss a lot of the potential changes and updates made to the Substrate.NetApi.
+They are very supportive to me.
+Last week, I had a chance to represent Ajuna at the Token2049. So, I was showing off all of the projects that have built on the Substrate.NetApi so far ^^.
+
+#### Is Plutonication made just for PlutoWallet?
+
+- Although the name may suggest it, it is not true. The name came from the hackathon, so we figured out a combination of __Pluto + Comunication =__ **Plutonication**. Once we figure out a better name, we will rename it to something more generic. It is totally meant to be used by anyone. We are willing to write a good documentation to make it simple for any developers to use.
+
+#### Can you share some user numbers or other metrics that show adoption of PlutoWallet?
+
+- It is in an MVP stage currently, meaning it works quite well, suports all of the important features, can be run on any platform and demonstrates well the idea of customizable layouts. It is on a good track to get released by the end of this year.
+
+#### Regarding deliverable 4.1, you mean polkadot.js apps, not the extension, correct?
+
+- I truly meant [polkadot.js extension](https://github.com/polkadot-js/extension) (https://polkadot.js.org/docs/extension/usage/).
+This Polkadot.js extension is implemented in polkadot.js.org/apps, which means, that it will also work with polkadot.js apps.
+
+- Also on the demo video, it already works with polkadot.js.org/apps ^^
+
+- What I am trying to say is that it is not just limited to polkadot.js.org/apps, but it can work with any dApp that implements the extension package, which most of the dApps did.
+
+#### Wallet Connect does have both a [Dapp integration guide](https://docs.walletconnect.com/advanced/multichain/polkadot/dapp-integration-guide) and a [wallet integration guide](https://docs.walletconnect.com/advanced/multichain/polkadot/wallet-integration-guide) for Polkadot. Can you compare to this and what is missing that your solution would provide?
+
+- WalletConnect for Polkadot is not available for c#.
+
+- WalletConnect also is not optimised for use with Substrate.NetApi.
+This is very important because all of the c# projects currently building on Polkadot ecosystem are using Substrate.NetApi.
+
+#### You point out that the only way to connect a mobile wallet to a Dapp is through Substrate Connect or Vault, but afaik mobile wallets such as Talisman and Fearless will also let you connect.
+
+- Substrate Connect / Vault are not very elegant and do not work on any device. The device needs to have access to a camera, which for example consoles do not have. Desktops also do not come with webcam out of the box. Smartwatches also do not have access to camera.
+
+- Talisman is not a mobile wallet. Sorry, I do not understand the second part of the question.
+
+#### How do you plan to get developers to use your solution?
+
+- The developers want to provide secure and easy to use dApps. If they do not have to deal about key management, they can focus on other parts of development.
+
+- For users, it is very risky to expose the private key. This way, they never expose their private key. The developers should recognize this risk and solve it with this easy to use solution.
+
+- As far as I know, this is the only solution so far for c# that allows the users to connect their wallet to a Substrate.NetApi dApp.
diff --git a/applications/PoCS.md b/applications/PoCS.md
new file mode 100644
index 00000000000..1223908cbd8
--- /dev/null
+++ b/applications/PoCS.md
@@ -0,0 +1,213 @@
+# Proof of Contract Stake (Pallet)
+
+- **Team Name:** Auguth Tech
+- **Payment Address:** BTC (bc1qdajpxy5wc6kcsdaaa4e760977nd03g86khay9g)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+#### One Sentence Summary
+
+*Forging Secure Public Networks through Staking Smart Contracts*
+
+#### Brief Description
+
+Blockchain technology, with the introduction of Ethereum protocol, impacted the ecosystem by introducing the concept of smart contracts. These self-executing contracts have enhanced the functionality and versatility of blockchain networks, opening up a wide array of decentralized applications and use cases. However, despite this pivotal development, there is absence of a consensus mechanism that places smart contracts at its core. Recognizing this critical gap, we present Proof of Contract Stake (PoCS) – The First Developer Centric Consensus.
+
+PoCS is an innovative staking system that leverages *contract gas history* to select block producers. PoCS integrates elements of both proof-of-work and proof-of-stake. We have introduced a novel concept of **'code-mining'** that incentivizes developers to actively participate in securing the network. By aligning the interests of developers with the network's security, PoCS introduces a dynamic where smart contract creators play a vital role in consensus. In addition, PoCS implements a system of *'stake scoring'*, taking into account factors such as contract age, reputation, and gas utilization. This design not only fortifies the network against collusion type attacks but also ensures a fair and secure environment for all participants. It also addresses a longstanding concern in blockchain consensus models – the 'nothing at stake' attacks . By introducing a non-fungible, non-transferable unit of scarcity for staking, PoCS effectively mitigates this vulnerability, making it a secure and reliable network. In addition, the stake accumulation attack in PoCS is time constraint and patterned which can be easily detected. This escalates costs over time and cannot be expedited with any external resources.
+
+#### Substrate Integration
+
+We have chosen Substrate as the foundation for our project's development due to a multitude of compelling reasons. Substrate provides a modular framework for blockchain development platform. By leveraging Substrate's extensive capabilities, we could design our consensus mechanism effectively as it aligns perfectly with our goal of creating a dynamic and adaptable blockchain network. Additionally, our project envisions a future where cross-chain interoperability is a key component. This vision closely resonates with the Polkadot ecosystem, which provides of parachains ecosystem. The parachain ecosystem would help us design a robust implementation and test its interoperability. While this part is still under active research, we foresee our consensus mechanism being well-suited for integration into the broader Polkadot network. Besides, one of the most noteworthy features of Substrate is its native support for WebAssembly (Wasm) built contracts. Considering the research and future extensions, we wanted to develop the consensus on Wasm built contracts.
+
+
+#### Team Interest
+
+Our interest in this project was sparked by a genuine enthusiasm for blockchain technology. Initially, we began as web3 developers, participating in hackathons and exploring dapp development. However, during one of these hackathons, we encountered notable limitations with the Ethereum Virtual Machine (EVM). Recognizing the need for a more robust solution, our research head, Joby Reuben, who has been researching blockchain for over 4 years, began to delve into various consensus mechanisms. Proof of Contract Stake (PoCS) stemmed out from his previous research and emerged as a promising avenue, and we've been dedicated to refining this concept for the past eight months.As we conducted our research, we identified the need for a WebAssembly (Wasm) environment to effectively implement this mechanism. This led us to the Polkadot ecosystem, which provided a suitable environment for our vision.
+
+In this landscape of ever-evolving blockchain technology we are poised to reshape the way we approach smart contracts and network security. The grants will help us validate our research and make it more robust with the para chain ecosystem. Thus, through this support, we aim to bring our vision to delivering a practical tool to the community and contributing to the ongoing evolution of blockchain technology.
+
+### Project Details
+
+#### Prior work - Research
+
+Our [PoCS research](https://jobyreuben.in/JOURNALS/pocs) is documented. We have also included [simulations](https://jobyreuben.in/JOURNALS/pocs#pocs-simulations-ethereum-pocs) on the research document to show how PoCS would behave if Ethereum used PoCS from its genesis block.
+
+#### Substrate implementation Design
+
+To implement PoCS on substrate we will be modifying `pallet-contracts` and `pallet-staking` under APACHE 2.0 license. We decided to proceed with this approach since both of these pallets provide the primary required functionalities. In addition to this substrate also provides a elaborate user interface for integrating contracts which will ease out our implementation. Since we will be implementing PoCS as a staking mechanism, we will be using `pallet-staking` with BABE + GRANDPA protocols to modify proof of stake.
+
+#### Outline of Core functionality
+
+1. **Fields to be added to Pallet-contracts**
+Every newly deployed contract will have three extra storage fields:
+* `AccountStakeInfo` (struct) : Struct maintainted for each contract call. It is updated everytime a contract is called.
+ * `owner` (AccountId) - Owner of the contract
+ * `delegateTo` (AccountId) - Set by the deployer and for the consensus to know who is the deployer. Only deployer can change this field
+ * `delegateAt` (Blocknumber) - The field is the current block height when the delegateTo field is updated
+* `ContractScarcityInfo` (struct field) - This field will be used to calculate the PoCS stake score. It will be updated anytime a transaction executes which corresponds to that contract. To calculate this we will use
+ * `reputation` (u64) - a parameter we assign to calculate the reputation of contract which depends on number of times it is called by a user or any other contract
+ * `recent_blockheight` (BlockNumberFor) - This is introduced to prevent vulnerabilities like DDoS attack
+
+
+2. Staking mechanism:
+In the context of Substrate, the integration of Babe and Grandpa protocols, alongside the Staking Pallet, complements the PoCS mechanism
+* Babe's deterministic block production process aligns with PoCS's commitment to security. Validators with higher reputation and weight history, as determined by the scarcity mapping, are incentivized to actively participate in proposing and validating blocks
+* Staking Pallet (Validator Selection): The Staking Pallet integrates with PoCS as validators selected based on their scarcity scores, are entrusted with the responsibility of proposing and validating blocks. This delegation ensures that validators with a proven track record of actively participating in the network are granted the authority to contribute to the consensus process.
+* Validator Reward Contract : Validator reward contract will act as a general middleware contract, which could be reusable across different apps/chains built over PoCS. We will build a validator contract which will not be a definitive but a reference contract which can be modified with a custom logic to implement custom reward distribution mechanisms.
+Outline of some basic functionalities:
+ 1. Claim Rewards: `claimRewards(address devAddress)`
+This function allows a developer to claim their rewards from the Validator Reward. For this it will verify that the caller is the owner of the contract calling the function and ensure that the contract is delegated to the validator.
+ 2. Calculate Reward Percentage: `calculateRewardPercentage(address contractAddress)`: This function calculates the percentage of rewards that the developer is eligible to claim based on the stake score of the associated contract.
+ 3. Transfer Rewards: `transferRewards(address devAddress, uint256 rewardAmount)`
+: This function transfers the calculated rewards to the developer from the contract. It ensures that the reward amount is valid and available in the contract.
+
+
+ Protocol design
+
+ 
+
+
+#### What your project is not or will not provide or implement
+We have structured our implementation into 3 milestones. In this grant our focus is to develop a first version which would implement pallet-contract to calculate the staking score in simplistic yet efficient way with above mentioned fields. It would handle
+* Stake score update when deployer deploys contract
+* Stake score update when a user calls contract function or other contracts call the contract function
+* Integration with proof of stake in substrate.
+
+We will continue to research as we implement, not all vulnerabilities might be handled in the very first version with above functionalities. But we will extend it to our future plans or extend the grants after accomplishing the milestones and scope in this proposal.
+
+### Ecosystem Fit
+Our project integrates with the Substrate framework, providing a modular and adaptable foundation for our innovative consensus mechanism. This positions us for potential integration into the broader Polkadot ecosystem, aligning with the vision of cross-chain interoperability through parachains.
+
+
+#### Target Audience
+Our primary target audience includes developers within the blockchain space, particularly those focused on Polkadot ink! ecosystem and its developers. Additionally, our project aims to serve the broader community of blockchain enthusiasts seeking to engage with a dynamic and secure consensus mechanism.
+
+#### What need(s) does your project meet?
+Our project addresses the critical need for a consensus mechanism that is developer-centric and tailored to the nuances of smart contract interactions. By incentivizing developers through our Proof of Contract Stake (PoCS) model, we empower them to actively participate in securing the network. This not only enhances network security but also fosters a more collaborative and inclusive blockchain ecosystem. Furthermore, our integration with Substrate and potential linkage to the Polkadot network addresses the need for cross-chain interoperability, opening up a realm of possibilities for decentralized applications and services.
+
+#### Similar Projects (How it is different)
+There are no similar projects in polkadot as well as other blockchains as of now since its proposing a new staking consensus.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Team Leader: Purva Chaudhari
+- Team Members : Ajay Joshua (Development) , Joby Reuben (Research)
+
+
+### Contact
+
+- **Contact Name:** Purva Chaudhari
+- **Contact Email:** puc7@pitt.edu
+
+### Legal Structure
+
+- **Registered Address:** Tamil Nadu, India - 624619
+- **Registered Legal Entity:** Auguth Tech Pvt Ltd (CIN : U72900TZ2019PTC033024)
+
+### Team's experience
+
+- **Purva Chaudhari**: Purva is a Masters Student in Computer Science at University of Pittsburgh. Her coursework is primarily includes on subjects of systems and cryptography. Her thesis is focused in blockchain (decentralised voting system). Prior to it, she has over 2 years of experience in working as a blockchain developer. After completing her bachelers in CS, she worked at Witness Chain for an year as backend blockchain engineer. She has experience in ethereum and solana development. She has also been part of Nethermind and Summer of Bitcoin internships during her bachelors.
+
+- **Ajay Joshua**: Ajay is a B.Tech graduate in Robotics and Automation. He is well-versed in Solidity with three years of practical experience in developing various web3 projects. During his coursework, Ajay has also worked on various projects, in brain-computer interface, AI-based power management system and distributed node-based space communication. His skills span across blockchain development and cybersecurity.
+
+- **Joby Reuben**: Joby is a the research lead. He is a dedicated researcher and has been delving deep in blockchains for over 2 years. He has profound understanding of Layer 1 protocols and is passionate to design Layer 1 consensus protocols. Currently he rewriting Ethereum yellow paper for developers as an open contribution. His elaborate research experience and realization of current shortcomings of blockchain has led to the idea of developing first developer incentivising consensus which we look forward to bring into reality.
+
+Overall we are a team of 6 members, 3 of which are core developers as mentioned above, one assists on basis of task and other 2 handle the non-technical work.
+
+### Team Code Repos
+
+- https://github.com/Purva-Chaudhari
+- https://github.com/I-Corinthian
+- https://github.com/jobyreuben
+
+### Team LinkedIn Profiles
+
+- https://www.linkedin.com/in/purva-chaudhari-02b12b178/
+- https://www.linkedin.com/in/ajay-joshua-a8a250176/
+- https://www.linkedin.com/in/jobyreuben
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 15 weeks
+- **Full-Time Equivalent (FTE):** 3-3.5
+- **Total Costs:** BTC equivalent to 25,000 USD
+
+### Milestone 1 - Pallet Contract Update
+
+- **Estimated duration:** 4 weeks
+- **FTE:** 3-3.5
+- **Costs:** BTC equivalent to 7,000 USD
+
+| Number | Deliverable | Specification |
+|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial to test out the additions |
+| 0c. | Testing | Unit testing and testing tutorial |
+| 0d. | Docker | Create docker image with updated pallets
+| 0e. | Article | Publish article for delineating the additions and workflow of consensus | |
+| 1. | Modified Substrate pallet-contracts for PoCS | 1. Try tight coupling of pallet-contracts with pallet-staking for interoperability of the pallets for PoCS consensus.
2. Add attributes to PoCS pallet and derive them. (eg: Contract scarcity struct, its related mappings etc ) |
+
+### Milestone 2 — Pallet staking Update
+
+- **Estimated duration:** 6 weeks
+- **FTE:** 3-3.5
+- **Costs:** BTC equivalent to 10,000 USD
+
+| Number | Deliverable | Specification |
+|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | Inline documentation of the code and a basic tutorial |
+| 0c. | Testing and Testing Guide | Unit testing and testing tutorial|
+| 0d. | Docker | Create docker image with updated pallets
+| 0e. | Article | Publish article for integrations and additions of new pallet logic|
+| 1. | Modify pallet staking for PoCS | Add custom functions and modify some existing functions of pallet staking and pallet contract to implement our attributes and make the pallets interact accordingly |
+
+### Milestone 3 — Validator Reward Contract, Testing and Documentation
+
+- **Estimated duration:** 5 weeks
+- **FTE:** 3
+- **Costs:** BTC equivalent to 8,000 USD
+
+| Number | Deliverable | Specification |
+|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
+| 0a. | License | MIT license |
+| 0b. | Documentation | Inline documentation of the code and a external contract documentation
We will publish an article/workshop that explains inner workings of PoCS and developer guide to build a PoCS enabled Substrate chain|
+| 0c. | Testing and Testing Guide | Unit testing with our validator reward ink! contract |
+| 0d. | Docker | Create docker image for entire consensus
+| 0e. | Article | Publish lite paper for the consensus |
+| 1 | Contract development | Design and implement a validator reward contract. (i.e Co-ordinator contract for rewarding).
Integrate it with PoCS consensus |
+| 2. | Alpha testing and publish paper | Alpha testing of entire consensus. Since it is a new consensus design, we have a separate milestone for analyzation of results over conducting an end to end test of the protocol
Standalone yellow paper|
+
+
+## Future Plans
+
+Once completed with this grant milestones,
+- Further research on democracy and validator penalty conditions
+- Moving towards testnet launch as a sister chain to Polkadot. Since it is first of its kind we will be actively discussing our future plans and research directions with the community.
+- We will be focussing more on making PoCS pallets interoperable with current popular Substrate pallets.
+
+## Referral Program :moneybag:
+
+- **Referrer:** muddlebee(Anwesh)
+- **Payment Address:** 0x92c856ef2e7c8c443030e2cc9e1739662ed3e8b1
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?**
+
+Through recommendation from [Builders Tribe](https://buidlerstribe.com/) to apply for W3F grants
+
+**If there are any other teams who have already contributed (financially) to the project.**
+
+No, Self Funded
+
+**Previous grants you may have applied for**
+
+No
diff --git a/applications/Polkadart.md b/applications/Polkadart.md
index 3f4bc5c714d..061bb6e16e8 100644
--- a/applications/Polkadart.md
+++ b/applications/Polkadart.md
@@ -1,7 +1,7 @@
# Polkadart
-- **Team Name:** JURIMETRIC TECNOLOGIA LTDA
-- **Payment Address:** 0xF9310880F753a2327146dD19EC2207E6bA482A19 (USDC)
+- **Team Name:** EXPERIO S M LTDA
+- **Payment Address:** 0x67a341f26A9c6211773Bf315B6226105cd1b2F24 (USDC)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3
## Project Overview :page_facing_up:
@@ -12,7 +12,7 @@
- Development of a library that allows users to connect to Polkadot/Substrate’s nodes on Flutter platform.
-- Our team is developing a ranking-based voting system based on the Substrate's based blockchain and for that, we need to create the Dart-substrate library. Today, there are multiple mobile applications built on Flutter and, until now, there is no possibility to connect to Substrate's nodes.
+- The library is already used in a few production environments to decode the storage and extrinsics from Substrate based chains. Today, there are multiple mobile applications built on Flutter and together with React Native it is one of the most popular frameworks to develop multi-platform mobile applications, but until now, there was no possibility to fully interact with Substrate's node.
### Project Details
@@ -22,7 +22,7 @@ This library will be written purely in Dart technology from scratch.
```
- Documentation of core components, protocols, architecture, etc. to be deployed:
```
-We will follow Polkadot specifications and, as a license for PolkaDart library, we will use Apache 2.0.
+We will follow Polkadot specifications and, as a license for Polkadart library, we will use Apache 2.0.
```
- What your project is _not_ or will _not_ provide or implement:
```
@@ -51,52 +51,37 @@ Pocket4 was similar to PolkaDart but it was discontinued for lack of progress an
### Team members
-- Lohann Ferreira, Lead Blockchain Architect
- Leonardo Custodio, Blockchain Engineer
-- Hanna Coutinho, iOS Developer
+- Lohann Ferreira, Lead Blockchain Architect
- Kawaljeet Singh, Flutter Developer
-- Luiza Adena Engers, Product Manager
-- Fabio Binder, Blockchain Engineer
- Gabriel Okura, Flutter Developer
- Bruno Pastre, Senior Flutter Developer
### Contact
-- **Contact Name:** Luiza Adena Engers
-- **Contact Email:** luiza@jurimetric.com.br
-- **Website:** www.jurimetric.com.br
+- **Contact Name:** Leonardo Garcia Custodio
+- **Contact Email:** leonardo@custodio.me
+- **Website:** https://www.linkedin.com/in/leogcustodio/
### Legal Structure
-- **Registered Address:** Rua Monsenhor Celso, 154, Centro, Curitiba-Paraná, Brasil.
-- **Registered Legal Entity:** Jurimetric Tecnologia Ltda.
+- **Registered Address:** Rua Capitao Souza Franco, 350 - Ap 22 - Curitiba/PR - Brasil
+- **Registered Legal Entity:** Experio S M Ltda
### Team's experience
-**Lohann Ferreira**
-
-Lohann have a deep understanding of Polkadot/Substrate stack amongst other blockchain technologies. Previously worked at [First Foundry](https://www.firstfoundry.co/) as Senior Software Engineer. Founder and lead engineer at [Jurimetric](https://jurimetric.com.br/). Co-founder of [Veever](https://veever.global/), which through the combination of beacons, a web platform, and a mobile app aims to assist people with visual impairment to easily get around and interact with the urban environment. He is focused on solving big problems with simple ambitious solutions.
-
**Leonardo Custodio**
-Leonardo has being working with Polkadot/Substrate stack for the past 14 months. At his current position he makes SDKs that allows game developers to work easily with substrate based chain. Before that he was the Lead Mobile Developer of Inovatso where he has created multiple applications for the general public like picPics and other entreprise applications using Flutter.
+Leonardo has being working with Polkadot/Substrate stack for the past 27 months. At his current position he makes SDKs that allows game developers to work easily with Substrate based chain. Before that he was the Lead Mobile Developer of Inovatso where he has created multiple applications for the general public like picPics and other entreprise applications using Flutter.
-**Fábio Binder**
-
-Binder has over 25 years of experience with development. Currently, he is the Program Head at PUCPR of the [Apple Developer Academy](https://www.linkedin.com/company/apple-developer-academy-pucpr/mycompany/). He was recognized as an Apple Distinguished Educator in 2019, for doing amazing things with Apple technology in and out of the classroom. He joined Jurimetric because he wants to be a part of the Web 3 movement as a hands-on developer of blockchain technology.
-
-**Hanna Coutinho**
+**Lohann Ferreira**
-Currently working as an iOS developer at Snowman Labs. She's a scholarship student at [Apple Developer Academy](https://www.linkedin.com/company/apple-developer-academy-pucpr/mycompany/) and is pursuing a Bachelor's Degree in Computer Information Systems, at PUCPR (Paraná, Brazil). Hanna's biggest dream is to work at a tech company where she can bring positive social impacts to minorities. A fun fact about her, she's also a Lawyer, but she found a true passion in technology, programming, and design.
+Lohann have a deep understanding of Polkadot/Substrate stack amongst other blockchain technologies. Previously worked at [First Foundry](https://www.firstfoundry.co/) as Senior Software Engineer. Founder and lead engineer at [Jurimetric](https://jurimetric.com.br/). Co-founder of [Veever](https://veever.global/), which through the combination of beacons, a web platform, and a mobile app aims to assist people with visual impairment to easily get around and interact with the urban environment. He is focused on solving big problems with simple ambitious solutions.
**Kawaljeet Singh**
Before starting to work as a full-time flutter developer at Rankanizer, Kawal was working as a freelance Flutter Developer at Inovatso and on other projects. In his free time, he loves to create open-source tools and plugins in dart to help the Flutter community. He is a blockchain enthusiast and is super dedicated to learning and bringing ideas to life.
-**Luiza Adena**
-
-Luiza is Jurimetric's Product Manager. She founded a legal tech called Arbi-ON and has experience with problem-solving through creative thinking. Luiza aims to make society more just and she believes Rankanizer has the potential to empower people equally.
-
**Gabriel Okura**
Gabriel is currently working as a mobile and backend developer at Hype Empreendimentos, and for the past year and a half, he has been having experience building apps in Dart with the Flutter framework. Previously worked with mobile game development at Opala Studios. He is excited about the opportunity to work on Rankanizer and to help build the PolkaDart library to increase his experience with blockchain technology.
@@ -111,21 +96,15 @@ He is fascinated about writing scalable, testable and maintainable code and has
- https://github.com/rankanizer/polkadart
- https://github.com/Lohann
- https://github.com/leonardocustodio
-- https://github.com/binderman
-- https://github.com/hannapcf
- https://github.com/justkawal
-- https://github.com/LuizaJurimetric
- https://github.com/gabrielokura
- https://github.com/pastre
### Team LinkedIn Profiles (if available)
-- https://www.linkedin.com/in/lohannferreira
- https://www.linkedin.com/in/leogcustodio
-- https://www.linkedin.com/in/binder
-- https://www.linkedin.com/in/hannapcf
+- https://www.linkedin.com/in/lohannferreira
- https://www.linkedin.com/in/kawal74153
-- https://www.linkedin.com/in/luizaadenaengers
- https://www.linkedin.com/in/gabriel-motelevicz-okura-aa95491b6
- https://www.linkedin.com/in/bpastre
@@ -145,11 +124,11 @@ Described above.
## Overview
-- **Total Estimated Duration:** 7 months.
+- **Total Estimated Duration:** 15 months.
- **Full-Time Equivalent (FTE):** 4.
-- **Total Costs:** 50,000 USD.
+- **Total Costs:** 75,000 USD.
-### Milestone 1 —
+### Milestone 1 — Completed
- **Estimated duration:** 4 months.
- **FTE:** 4.
@@ -166,7 +145,7 @@ Described above.
| 1c. | Tests | Unit tests for deliverables above |
-### Milestone 2 —
+### Milestone 2 — Completed
- **Estimated duration:** 1 month.
- **FTE:** 4.
@@ -182,23 +161,54 @@ Described above.
| 2b. | Websockets | We will add websockets support to the above. |
| 2e. | Tests | Unit tests for deliverables above |
-### Milestone 3 —
+### Milestone 3 — Ongoing
-- **Estimated duration:** 2 months.
-- **FTE:** 4.
-- **Costs:** 15,000 USD.
+- **Estimated duration:** 6 months
+- **FTE:** 2.
+- **Costs:** 20,000 USD.
+|Number|Deliverable| Specification |
+|:---: | --- | --- |
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | We will provide markdown documentation of how to install and use the API. |
+| 0c. | Testing Guide | We will provide sample scripts on how to use it. |
+| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test the PoC. |
+| 0e. | Article/Workshop | We will publish an example flutter project using the library to explain what was done and how to use it. |
+| 3a. | Substrate Uri | Implement Substrate's standard derivation format that applies to seeds and mnemonics. |
+| 3b. | Encrypt/Decrypt | Use Substrate's Bip39 password to encrypt/decrypt seeds and mnemonics. |
+| 3c. | Ed25519 | Support Ed25519 signatures and key derivation |
+| 3e. | Sign & Verify | Sign and verify messages using ed25519 keypairs |
+| 3f. | Substrate Signed Extensions | Support substrate's signed extensions |
+| 3g. | AssetHub Signed Extensions | Support AssetHub's signed extensions |
+| 3h. | Transaction Subscriptions | Support transaction subscription |
+| 3i. | Event Subscriptions | Support runtime event subscription |
+| 3j. | Keyring | Create a package that manage a set of keys in a consistent environment |
+| 3k. | Crypto | Utilities needed for signing, hash and encode/decode messages |
+| 3l. | Tests | Unit tests for deliverables above |
+| 3m. | Pub.dev | Publish to pub.dev |
+
+### Milestone 4 —
+
+- **Estimated duration:** 4 months
+- **FTE:** 2.
+- **Costs:** 20,000 USD
+
|Number|Deliverable| Specification |
|:---: | --- | --- |
| 0a. | License | Apache 2.0 |
| 0b. | Documentation | We will provide markdown documentation of how to install and use the API. |
| 0c. | Testing Guide | We will provide sample scripts on how to use it. |
| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test the PoC. |
-| 0e. | Article/Workshop | We will publish an example flutter project using the library to explain what was done and how to use it. |
-| 3a. | Keyring | We will port the keyring management |
-| 3d. | Crypto | We will add the utilities needed for signing transactions |
-| 3e. | Tests | Unit tests for deliverables above |
-| 3f. | Pub.dev | Publish to pub.dev for V1.0.0 |
+| 4a¹. | Research sr25519 | More research needs to be done to decide what is the best path forward to support sr25519, one of the following might be done |
+| 4a². | Rewrite Schnorrkel in Dart | Rewrite [schnorrkel](https://github.com/w3f/schnorrkel) in pure dart |
+| 4a³. | Use rust schnorrkel | Make dart wrappers to use rust bindings to use schnorrkel lib |
+| 4b. | Ecdsa/Secp256k1 | Support Ecdsa/Secp256k1 signatures and key derivation |
+| 4c. | Sign & Verify | Sign and verify messages using sr25519 and ecdsa keypairs |
+| 4e. | Custom RPC | Support custom RPC methods |
+| 4f. | Custom Signed Extensions | Support custom signed extensions |
+| 4g. | Multisig Account | Implement's Substrate's Multisig Account |
+| 4h. | Tests | Unit tests for deliverables above |
+| 4i. | Pub.dev | Publish to pub.dev |
## Future Plans
diff --git a/applications/Polkadot-Protocol-Conformance-Tests.md b/applications/Polkadot-Protocol-Conformance-Tests.md
new file mode 100644
index 00000000000..ed9e978e725
--- /dev/null
+++ b/applications/Polkadot-Protocol-Conformance-Tests.md
@@ -0,0 +1,154 @@
+# Polkadot Protocol Conformance Tests Research Proposal
+
+- **Team Name:** [LimeChain](https://github.com/LimeChain)
+- **Payment Address:** 14dut6zGgdVmKijePZzrQAy2gZ6FmMDmzzp7VqjzPV9E4ujR (USDT on Polkadot AssetHub)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3
+
+## Project Overview :page_facing_up:
+
+This research proposal is in response to the currently open [Polkadot Protocol Conformance Tests RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/polkadot-protocol_conformance_tests.md).
+
+### Overview
+
+Polkadot has made substantial progress over the last few years in terms of client diversification. Currently, there are 4 existing host implementations with varying features and protocol support: [Polkadot](https://github.com/paritytech/polkadot) by Parity, [Kagome](https://github.com/soramitsu/kagome) by Soramitsu, [Gossamer](https://github.com/ChainSafe/gossamer/) by ChainSafe, and [Fruzhin](https://github.com/limechain/fruzhin) by LimeChain. Having a healthy client diversity is beneficial to every blockchain protocol as it becomes more decentralised and less bug-prone. Neglecting these aspects has resulted in halting block production for some blockchain protocols in the past.
+
+The nature of software is such that it's never perfect, and bugs happen. Therefore, multiple host implementations come with a higher probability of implementation-specific issues. It's important for a blockchain protocol that takes great pride in its decentralisation, such as Polkadot, to have a protocol compliance testing suite that verifies the behaviour of each implementation. The more comprehensive the testing suite is, the stronger security guarantees the protocol can provide.
+
+The goal of this project is to prepare for the redesign of the existing [conformance tests repository](https://github.com/w3f/polkadot-tests). Our team envisions the redesigned testing suite to be easily extensible and flexible, welcoming contributors to enhance it with their domain-specific knowledge. Concerns have been raised regarding the "adapter" approach that the existing testing suite has taken and that the chosen language ([Julia](https://julialang.org/)) is out of sync with the one for Polkadot ([Rust](https://www.rust-lang.org/)). This proposal aims to lay the groundwork for resolving these issues by delving deep into the biggest obstacle that stands in the way: finding the correct level of abstraction and tooling that will be the cornerstone for every kind of test scenario.
+
+### Project Details
+
+### A host-agnostic approach
+
+A conformance testing suite should be host-agnostic, meaning that, for the most part, the tests shouldn't be concerned with the specific Host implementation against which they are being executed. The Host exposes several interfaces that enable conformance testing; however, it’s a complex piece of engineering, and there will always be protocols and functionalities without an exposed interface. Moreover, there are integration tests that can't be conducted using an API. These scenarios are as important as the previous ones because the Host can't function properly if the modules don't work seamlessly with one another.
+
+### Host API
+
+The Host API consists of a set of functions that the Host exposes to the Runtime. These functions are used to access external resources for various purposes, including storage access, manipulation, memory allocation, and more. If a method within the API contains a bug, it has the potential to push the Host into an incorrect state transition. Such a scenario could lead to undefined consequences, particularly if a significant number of nodes experience the same issue.
+
+### SCALE
+
+Substrate employs a lightweight and efficient encoding and decoding mechanism to optimise the transmission and reception of data across the network. This protocol, known as the SCALE codec, plays a vital role in serialising and deserialising data. It serves as a critical component for data transfer across the peer network and facilitates communication between the Runtime and the Host. Consequently, the presence of comprehensive tests for SCALE encoding and decoding holds immense significance in ensuring the proper functionality of the Host.
+
+### State Trie
+
+The state trie is another crucial part of the Host. A radix-16 state is the data structure that Substrate uses to store the state of the blockchain. Without thoroughly tested state trie functionalities, the Host may transition to an incorrect state and get slashed if it's a block producer.
+
+### BABE & GRANDPA
+
+[BABE](https://spec.polkadot.network/sect-block-production) & [GRANDPA](https://github.com/paritytech/finality-grandpa) are the bread and butter of the consensus-reaching module for Polkadot. However, finding the right tools and approach to test the block production and finalisation protocols independently of the Host’s environment is a challenge that is yet to be overcome by any team.
+
+### Zombienet
+
+[Zombienet](https://github.com/paritytech/zombienet) aims to be a testing framework for Substrate-based blockchains, providing a CLI tool that allows users to spawn and test ephemeral networks. The assertions used in the tests can include on-chain storage, metrics, logs, and custom JavaScript scripts that interact with the chain
+
+Our team has successfully utilised Zombienet to run PVF conformance tests as part of another W3F grant. This is the reason why we believe that Zombienet has the potential to be the go-to framework for running conformance tests on the Hosts. The research is going to focus on Zombienet, as well as on the new [Zombienet SDK](https://github.com/paritytech/zombienet-sdk).
+
+### Research Scope
+
+The main focus of the research will be on investigating each of the aforementioned protocols and functionalities and how they can be tested in a host-agnostic manner. Based on our preliminary research and the work we've conducted on the PVF conformance testing suite, our team believes that Zombienet can serve as the foundation for the testing suite. The team will examine whether Hosts and Zombienet have the required feature set to support such testing scenarios. If this is not achievable, the team will document the missing components so that they can be identified and potentially contributed in a future proposal.
+
+Our team acknowledges that, for certain Hosts, having the Host API, SCALE, and State Trie as standalone artifacts could be beneficial for Host developers during the early phases of their implementation. However, this proposal primarily focuses on adopting a host-agnostic approach for Hosts that are already functioning with the already existing tests. Depending on the research outcomes, our team may subsequently introduce a new proposal involving the redesign of the conformance repository. In this redesign, the tests would be separated into a standalone artifact and transformed into Zombienet tests.
+
+### Ecosystem Fit
+
+By delivering a research document containing insightful information about the necessary steps to commence the redesign of the Polkadot Conformance Testing repository, we aim for it to serve as a catalyst to initiate the development process
+
+Initially, the Polkadot Conformance Testing repository will be situated in close proximity to the realm of Polkadot Hosts. Its primary target audience will be Host developers seeking comprehensive testing for their Hosts. Other individuals who might find this project valuable include experts from the Polkadot specification team, who can contribute their expertise in specific scenarios.
+
+## Team 👥
+
+### Team members
+
+- Viktor Todorov
+- Maksim Dimitrov
+- Kristiyan Veselinov
+
+### Contact
+
+- **Contact Name:** Kristiyan Veselinov
+- **Contact Email:** kris@limechain.tech
+- **Website:** [https://limechain.tech](https://limechain.tech/)
+
+### Legal Structure
+
+- **Registered Address:** Bulgaria, Dragan Tsankov 23A, 1113, Sofia, Bulgaria
+- **Registered Legal Entity:** LimeLabs Ltd.
+
+### Team's experience
+
+At LimeChain, we possess considerable expertise in developing various tools, including [Gosemble, a framework for building Substrate compatible Runtimes in Go](https://github.com/LimeChain/gosemble), [Fruzhin, a Host implementation in Java](https://github.com/limechain/fruzhin), [a framework for runtimes in AssemblyScript](https://github.com/LimeChain/subsembly), a framework for runtimes in AssemblyScript. On top of that, we’re working on a [Parachain Validation Conformance Testing suite](https://polkadot.polkassembly.io/motion/389), have substantial experience in Rust/WebAssembly developer tooling from [Matchstick](https://github.com/limeChain/matchstick/) and actively contribute to infrastructure projects in Cosmos and Hedera Hashgraph.
+
+### Team Code Repos
+
+- [https://github.com/LimeChain](https://github.com/LimeChain)
+
+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/vikinatora](https://github.com/vikinatora)
+
+### Team LinkedIn Profiles (if available)
+
+- [https://www.linkedin.com/in/viktor-todorov-8a7434122/](https://www.linkedin.com/in/viktor-todorov-8a7434122/)
+- [https://www.linkedin.com/in/chris-veselinov/](https://www.linkedin.com/in/chris-veselinov/)
+
+## Development Status :open_book:
+
+No actual development has been made for this RFP. However, the team has spent a significant amount of time delving into the Host’s specification as part of the Java Host implementation we're currently working on. Additionally, our work on the PVF conformance testing suite has enhanced our understanding of how to address challenging-to-test sections of the code.
+
+## Development Roadmap :nut_and_bolt:
+
+The primary framework under consideration for this research will be Zombienet, as it already provides the groundwork for these types of tests. Each of the steps outlined below will be dedicated to investigating the creation of Zombienet tests for the specified functionalities. The team will also document in the research report the development steps required to enable testing of the specified functionality using Zombienet.
+
+Outlined below are the testing scenarios for each Host module that will be the focus of the research:
+
+1. Host API
+ 1. Trie
+2. SCALE
+ 1. SCALE encoding
+ 2. SCALE decoding
+3. State Trie
+ 1. Trie encoding
+ 2. Trie decoding
+4. BABE
+ 1. Block import
+ 2. Block validation
+5. GRANDPA
+ 1. Block import
+ 2. Block validation
+
+### Overview
+
+- **Total Estimated Duration:** 8 working weeks
+- **Full-Time Equivalent (FTE):** 2
+- **Total Costs:** $49280
+
+### Milestone 1 — Polkadot Conformance Testing Suite Research
+
+- **Estimated duration:** 8 working weeks
+- **FTE:** 2
+- **Costs:** $49280
+
+| Number | Deliverable | Specification |
+| --- | --- | --- |
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | We will provide inline documentation, as well as README file with how the suite can be executed. Additional information will be provided on how to contribute. |
+| 0c. | Testing and Testing Guide | Documentation will be provided that showcases how the testing suite can be executed for different scenarios and hosts. |
+| 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 what was done/achieved as part of the grant. |
+| 1. | Host API Research | Research the feasibility of using Zombienet as the framework for executing Host API tests. |
+| 2. | SCALE Research | Research the feasibility of using Zombienet for conducting SCALE encoding and decoding tests. |
+| 3. | State Trie Research | Research the feasibility of using Zombienet for conducting State Trie encoding, decoding and generation tests. |
+| 4. | BABE Research | Research the feasibility of using Zombienet for conducting BABE tests. |
+| 5. | GRANDPA Research | Research the feasibility of using Zombienet as the framework for conducting GRANDPA tests. |
+| 6. | Research Findings | A research document will be delivered documenting the team’s findings, as well as outline a high-level path forward for the conformance testing suite. |
+
+## Future Plans
+
+Based on the research findings, our team could formulate a proposal for implementing these tests and restructuring the conformance testing suite with the new approach, and/or contributing the necessary features that would enable Zombienet to be utilised for these purposes.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?**
+
+At LimeChain, we have been contributors to the Polkadot ecosystem for the last 3+ years as we believe in a multi-chain future, based on interoperability and decentralisation. Principles that are built into the core of the Polkadot network. We possess considerable expertise in developing various tools, including [Gosemble, a framework for building Substrate compatible Runtimes in Go](https://github.com/LimeChain/gosemble), [a framework for runtimes in AssemblyScript](https://github.com/LimeChain/subsembly),, and [Parachain Validation Conformance Testing](https://polkadot.polkassembly.io/motion/389). Additionally, we have substantial experience in Rust/WebAssembly developer tooling from [Matchstick](https://github.com/limeChain/matchstick/) and have actively contributed to infrastructure projects in Cosmos, Near, Filecoin, Ledger and Hedera Hashgraph.
diff --git a/applications/QSTN.md b/applications/QSTN.md
index 4423b4b794b..7d045fb8e0d 100644
--- a/applications/QSTN.md
+++ b/applications/QSTN.md
@@ -8,62 +8,76 @@
### Overview
-- QSTN is a web application where users participate in surveys, quizzes and short questionnaires to earn virtual credit.
-- QSTN is a blockchain enabled market research portal where users answer questions, earn credit and spend these rewards in our digital marketplace for tokenized goods (e.g. NFTs, metaverse wearables).
+- QSTN is a Web3 survey marketplace where businesses fund surveys, reward participants, and uphold user privacy through our data wallet-driven profiles.
+- QSTN is a cutting-edge platform that combines AI-driven surveys with a secure data wallet. Our solution empowers users to earn digital rewards from surveys while maintaining privacy. We're revolutionizing data monetization in the digital age.
-When we agree to terms and conditions, most of the time, our data gets sold and commodified without permission or compensation. QSTN acts as an “interface” for consumers to pay gate their information towards businesses.
+At QSTN, we aim to revolutionize the data collection landscape by addressing key challenges faced by traditional survey platforms. We understand that user engagement is essential for successful data collection, which is why we offer a gamified experience to incentivize users and boost response rates. Through our platform, businesses can easily fund surveys using digital tokens or NFTs, streamlining payment processes and ensuring faster and more efficient transactions.
-By compensating users for their data, we provide incentive for rich and meaningful insights. This information is then sold and accessed by our partners for market research purposes.
+One of the most significant concerns in data collection is data privacy and security. We prioritize user trust and confidence by providing our data wallet, Cubby, which allows users to maintain full control over their data. This secure environment ensures that users' personal information remains private, making them more willing to share valuable insights. Additionally, we equip businesses with AI-assisted survey creation and advanced data analytics tools, enabling them to derive meaningful insights from survey responses and make data-driven decisions. Our strategic partnerships with prominent blockchain projects like NEAR and Stellar further enhance our platform's capabilities and foster interoperability within the Web3 ecosystem. Through these solutions, we aim to create a compelling and user-centric data collection platform that empowers businesses and individuals alike.
-Since winning the Octopus Network Star Prize, we realize the importance of interoperability and the low transactional fees offered by Substrate due to their sharded blockchain mechanism; Octopus Network is supporting our app-chain.
-
-- Building on this, we would like Polkadot to be the next blockchain we implement; allowing its users to answer questionnaires, earn virtual credit and spend it for digital rewards minted and issued on Polkadot (e.g. NFTs).
+Demo: NEAR Protocol
+https://drive.google.com/file/d/1P2NRbIx2VZhfIQ6FHKO5_YOyhFZHjbfW/view?usp=sharing
+
+- Building on this, we would like Polkadot to be the next blockchain we implement; allowing its users to answer questionnaires, earn DOT rewards and mint NFTs upon completion.
The key to our platform is allowing users to monetize their personal information in a low gas, scalable environment and Polkadot meets both of these requirements. By supporting this initiative, the Web3 Foundation is investing in data infrastructure for the entire DOT ecosystem as well as creating a new “Play-to-Earn” model for data aggregation.
-For scope, QSTN can be broken down into three different user experiences:
- 1. User experience - general users create an account, complete on-boarding process and then have the ability to answer 5 daily questions in return for credit which can be spent within our NFT marketplace
+For scope, QSTN can be broken down into two different user experiences:
- 2. Business experience - businesses and corporate entities (e.g. DAOs and protocols) can establish an account to create their own questionnaire portal, reward users for their participation and track response rate
+1. User experience - users create an account and then have the ability to complete 3 daily surveys in return for DOT tokens and NFTs
+2. Business experience - businesses create an account and build their own survey, rewarding users for their participation in DOT tokens and NFTs
- 3. Commission experience - businesses and corporate entities can pay a fee to have their questions slipped into the "User View" rotation and glean insights from our daily, active audience for their own market research purposes
-
-We want to bring all three user experiences to the DOT ecosystem, supporting the general user in scope 1, businesses and protocols who want to manage their own questionnaire in scope 2 and the opportunity for more traditional Web2 businesses to collect market research from Web3 audiences in scope 3.
+We want to bring both experiences to the DOT ecosystem and allow businesses to fund, track and engage users via their own surveys with the assistance of AI.
+
+### Project Details
-- Founded by NYU graduate Orrin Campbell, QSTN was birthed by a recorded conversation with astrophysicist Neil deGrasse Tyson. During the interview, Neil argued that even if software is ‘free’, companies still profit from the sale, transfer, and storage of our information.
+### Ecosystem Fit
-For example, did you know Google makes almost $120 million dollars a day in advertising revenue (e.g. targeted ads, placements)? Orrin thought about how to creatively address this problem and deliver his “promise to save the world.”
+- QSTN is an innovative Web3 survey platform that combines blockchain, gamification, and AI to revolutionize data collection. Businesses can easily fund surveys using digital tokens or NFTs, offering users enticing rewards for their participation. Our data wallet, Cubby, ensures users maintain full control over their data, ensuring privacy and security.
-Orrin has released NFTs with Mintbase, spoken on Cryptovoxels and Somnium panels as well as created a large social following behind his afrofuturistic aesthetic.
+To ensure this vision becomes a reality, we're harnessing the power of Safe's decentralized custody protocol and collective asset management platform. Users signing up on QSTN have their email addresses utilized to create individualized Safe vaults, powered by Web3 authentication. This integration enables users to complete surveys, earn zero-knowledge proofs, and subsequently claim their rewards directly within their EVM wallet.
-Completing the QSTN team triad are the Suriel brothers, who Orrin met at NYU. Jose Suriel is an NYU graduate who handles project management at Forge AI — bringing this expertise to assisting the development and timeline of the QSTN marketplace.
+SAFE is a non-custodial solution by Consensys (https://safe.global/), it facilitates wallet creation utilizing email addresses. Currently, SAFE lacks support for Polkadot. Given this, we will enable users to interact directly with the pallet, easing the reward redemption process post-survey completion. The wallet we will use is Polkadot JS wallet.
-Anibal Suriel is Jose’s twin brother and our head of legal, he is registered in New York and Miami; leveraging his time at KARM to create the legal framework and guidelines around data, compliance, and overall best practices.
+We aim to take advantage of the low gas, scalable environment offered on DOT to allow users to earn DOT, mint NFTs and transfer assets without exorbitant transactional fees.
-With a desire to build meaningful products and experiences, Orrin founded QSTN with the aim to empower internet users and provide alternative means of passive income, aided by the invaluable expertise of the notorious Suriel duo.
+- Right now, our target audience can be broken down in the following groups:
-### Project Details
+A. Agencies
+* Marketing agencies
-### Ecosystem Fit
+*Target agencies to use for experiential campaigns + source to relevant clients
-- QSTN is Web3 infrastructure to accelerate the adoption of data monetization. Since users can earn with or without a Web3 wallet, but have the option to create one, shows we are designed to be a Web2 on-ramp into the world of Web3.
+B. Brands
+* Airline
+* Beauty brands
+* Food delivery
+* Record labels
-We aim to do this by taking advantage of the low gas, scalable environment offered on DOT to allow users to earn credits, mint NFTs and transfer assets without exorbitant transactional fees.
+*Target customer experience, customer success and marketing team
-Our design is a centralized system “wrapped” with Web3 extensions so that users can sign up using Twitter or Facebook but still earn credits and NFTs once they decide to create a wallet.
+C. Educational institutions
+* Colleges
+* Universities
-- Right now, our target audience can be broken down in the following groups:
-1. Data privacy enthusiasts (Web2 and Web3)
-2. High school and college students seeking additional income
-3. Web3 DAOs and Protocols which need to capture market research (e.g. DAO governance)
-4. Web2 users wishing to matriculate to Web3 but no upfront capital or resources to get into the space
+*Target professors, teachers and researchers
-Currently, we have over 3,000 sign-ups for the waitlist, confirmed private test sessions with Encode Club, Octopus Network and a couple projects on NEAR Protocol.
+D. Web3
+* Analytics firms - Addressable, Chainalysis, Dune Analytics, Kaiko, Messari, Nansen, Pantera Capital, QuickNode, Solidus Labs
+* DAOs
+* Foundations
+* NFT communities
+* Exchanges
-Since we also have a desire to partner with Web2 organizations to help demonstrate the value of our platform, we are currently in talks with the following educational institutions to run private sessions.
-- Jack & Jill of America, Inc.
-- New York University
-- The Gray Matter Experience
+*Target marketing, community outreach and developer support
+
+Here are some notable milestones we've achieved since inception:
+
+1. Secured a position in Outlier Venture's NEAR Base Camp, successfully closing our pre-seed round.
+2. Developed a data wallet feature, now generating zero-knowledge proofs upon survey completion.
+3. Integrated AI to assist businesses in crafting surveys and evaluating authenticity of responses through a "credibility" score.
+4. Garnered preliminary interest from notable entities like NYU, Estée Lauder, and L'Oréal for potential test partnerships, in collaboration with the NEAR Foundation.
+5. Were honored with acceptance into the Polkadot Blockchain Academy, although a visit was precluded due to visa constraints.
- Our platform is able to act as a Web3 on-ramp because our design easily onboards novice, less experienced internet users. This is important because in our initial feedback, we learned a lot of internet users want to get into blockchain but do not have the capital, resources or know where to start.
@@ -77,7 +91,7 @@ QSTN builds on their concept by offering more exciting, engaging rewards, increa
Our unique offering is the ability for Web2 users to answer questions, earn credits and buy NFTs within a "gas-less" environment but having the option to connect their wallet and mint once familiar with the technology.
-We spent the past year participating in over 5 accelerators to help drive the brand awareness within the Web3 space and ensure we become the "go-to" market research portal in blockchain.
+We spent the past year participating in over 7 accelerators to help drive the brand awareness within the Web3 space and ensure we become the "go-to" market research portal in blockchain.
- There has been an increase in the “Play-to-Earn” model and a couple players who are making noise in the space would include Rabbit Hole (educational), NEAR Crowd (micro task), Axie Infinity (gaming), Pi (validation), and Sweat Coin (exercise).
@@ -87,27 +101,43 @@ We see a market opportunity to use this model for data aggregation, gamifying ma
### Team members
-- Orrin Campbell – QSTN founder, CEO and blockchain architect who will be designing the workflow and user experience **team leader**
+- Orrin Campbell, CEO: A marketing graduate from NYU, Orrin is an influential figure in the entertainment industry with millions of streams and followers. His media presence has been showcased on platforms like Dr. Phil, and his degree in marketing adds valuable insights to QSTN's growth strategy.
-Twitter - https://twitter.com/realorrin
+Anibal Suriel, Chief Legal Officer: An NYU alum with a remarkable legal career, Anibal has worked for prestigious firms like KARM and R3. He possesses extensive legal expertise and is admitted to the bar in three states: New York, Florida, and Washington DC.
-Instagram - https://instagram.com/realorrin
+Brigitte Pinewiski, Chief Partnership Officer & Web3 Physician: An author of "Wealthcare: Demystifying Web3 and the Rise of Personal Data Economies," Brigitte is also a Healthcare Advisor, Nex Cubed member, and TiE Board and Charter Member. Her expertise in Web3 and AI adds a unique perspective to the team, aligning with QSTN's focus on innovation in the healthcare realm.
-Linkedin - https://linkedin.com/in/realorrin
+Carlos Guiamaraes, CTO & Lead Developer: Carlos brings a strong technical acumen to QSTN. As a skilled developer for over 15 years, his contributions are integral to the back-end architecture and tool integration, ensuring a seamless and efficient platform.
-GitHub - https://github.com/@qstnus
-
-- Anibal Suriel - QSTN Head of Legal **team member**
-
-Linkedin - https://linkedin.com/in/anibal-suriel-esq
+Eduardo Gomes, Junior Developer: A promising talent, Eduardo contributes to QSTN's development efforts. With his skills and passion for identity, he adds value to the KYC and verification of users within the QSTN platform.
-Lafi Raed – QSTN Lead Developer **team member**
+Melanie Zhang, Creative Director: An NYU graduate with a keen eye for design and user experience, Melanie's artistic vision enriches the platform's aesthetics and fosters engagement with QSTN's users.
-GitHub - https://github.com/shadow111
+Daniel Fadely, Financial Analyst: An NYU alum with a strong finance and investment background, Daniel's involvement in opening and running the investment club at NYU, along with experience in managing various portfolios, enhances the financial planning and analysis for QSTN.
-Phillip Coleman - Entreprenuer In Residence **team member**
-
-Linkedin - https://www.linkedin.com/in/phillip-coleman-791b1475
+- Orrin Campbell – QSTN CEO
+Twitter - https://twitter.com/realorrin
+Instagram - https://instagram.com/realorrin
+Linkedin - https://linkedin.com/in/realorrin
+GitHub - https://github.com/@qstnus
+
+Anibal Suriel - QSTN CLO
+Linkedin - https://linkedin.com/in/anibal-suriel-esq
+
+Brigitte Piniewski - QSTN CPO
+LinkedIn - https://www.linkedin.com/in/brigittepiniewski/
+
+Carlos Guiamaraes – QSTN CTO & Lead Developer
+GitHub - https://github.com/sekmet
+
+Eduardo Gomes - QSTN Junior Developer
+GitHub - https://github.com/Eduardogbg
+
+Melanie Zhang - Creative Director
+LinkedIn - https://www.linkedin.com/in/melanie-y-zhang/
+
+Daniel Fadely - Financial Analyst
+LinkedIn - https://www.linkedin.com/in/daniel-f-436377203/
### Contact
@@ -139,11 +169,30 @@ https://medium.com/oct-network/spring-2022-octopus-accelerator-star-prize-winner
5. QSTN is 1 of 5 teams to receive the official Star Prize
https://www.youtube.com/watch?v=72QqZ6MIxeo
-Orrin Campbell
- Along with his entrepreneurial pursuits in Web3, Orrin has a large following in entertainment due to his national television appearance on Dr. Phil during an hour long episode about his experience as a "cyborg from the future."
-
- In an attempt to build on this platform, Orrin has amassed a large following on social media who follow his advice and input on topics ranging from music, fashion, entertainment and technology (Web3).
-
+6. QSTN is featured on XFounders -
+https://youtu.be/35Mv9rt5KHQ
+
+7. QSTN wins the Parsiq unicornization contest -
+https://hub.parsiq.net/unicornization
+
+8. QSTN participates in the Mintbase Demo Day -
+https://blog.mintbase.xyz/wrapping-up-mintbases-demo-day-f13fd192c8fc
+
+9. QSTN presents at the Mastercard x NEAR Demo Day -
+https://youtu.be/TkfHLgsBxiE
+
+Orrin Campbell (Founder bio) -
+
+Orrin is a multi-faceted entrepreneur and entertainer, renowned for his innovative strides in the fintech and entertainment sectors. As the founder of QSTN, Orrin combines his passion for technology and entertainment to revolutionize data monetization through gamification.
+
+A recent graduate of NYU Stern School of Business, Orrin's journey is anything but ordinary. Before delving into fintech, he made waves as an entertainer, amassing millions of streams on Spotify. His charisma and talent led him to a highly publicized appearance on Dr. Phil's national television show, which catapulted him to social media stardom with 250,000 followers on TikTok, 15,000 on Instagram, and 40,000 on YouTube.
+
+Leveraging his newfound audience and background in entertainment, Orrin ventured into fintech with a vision to empower individuals to take control of their data. He founded QSTN, a groundbreaking platform that bridges the gap between data collection and user engagement through gamification and rewards.
+
+In just two years, Orrin’s leadership and innovation at QSTN have been recognized with wins in two blockchain competitions. He has also been an active participant in prestigious accelerators, including Verizon, GitHub, and NYU Future Labs. Orrin’s visionary approach has piqued the interest of giants like L'Oréal and Estée Lauder, with whom discussions are ongoing for potential collaborations. Additionally, NYU, his alma mater, is among the entities showing interest in QSTN. The platform has already garnered the attention of over 3,000 test users, marking a promising start.
+
+Orrin's combination of entertainment flair and technological acumen positions him as a trailblazer in the fintech space. Through QSTN, he is not just transforming data collection but reshaping the very fabric of user engagement and empowerment in the digital age.
+
Dr. Phil episode -
https://www.youtube.com/watch?v=ReRddYVYfHU
@@ -156,16 +205,15 @@ https://tiktok.com/@realorrin (250,000 followers)
https://instagram.com/realorrin (18,000 followers)
https://youtube.com/c/realorrin (41,000 followers)
-
### Team Code Repos
- https://github.com/qstnus
-- https://github.com/qstn-ansr
-- https://github.com/shadow111
+- [https://github.com/qstn-ansr ](https://github.com/orgs/QSTN-US/repositories)
+- [https://github.com/shadow111 ](https://github.com/sekmet)
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/shadow111
+- [https://github.com/shadow111](https://github.com/sekmet)
### Team LinkedIn Profiles (if available)
@@ -187,13 +235,13 @@ Article 3: https://news.bloomberglaw.com/litigation/google-plus-7-5-million-priv
### Overview
-- **Total Estimated Duration:** 12 months
+- **Total Estimated Duration:** 15 months
- **Full-Time Equivalent (FTE):** 8 employees (4 developers, 3 designers, 1 blockchain architect [Orrin])
- **Total Costs:** 10,000 USD
### Milestone 1 Example — Implement Substrate Modules
-- **Estimated duration:** 12 months
+- **Estimated duration:** 15 months
- **FTE:** 8 employees
- **Costs:** 10,000 USD
@@ -204,22 +252,22 @@ Article 3: https://news.bloomberglaw.com/litigation/google-plus-7-5-million-priv
| 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 a Medium article that documents our transition to Polkadot and details how users of QSTN can connect their DOT wallet to our application, mint & transfer purchased media onto the DOT blockchain as well as save their survey ID on-chain on a local substrate chain.
-| 1. | Survey pallet | We will create a Substrate module that will allow users to create a survey, invite other users to create a survey for their business, add questions (metadata), remove questions (metadata), give permission as to who can answer and list created surveys.
-| 2. | Survey pallet UI | We will create a new UI for DOT users to be able to ask questions, receive credit and screenshot their response on-chain; these design assets will include landing pages and layouts which we will open source to the DOT community
-| 3. | Substrate chain | The survey pallet of our custom chain will interact in such a way to allow users to connect their DOT wallet to our application, mint media on a local substrate chain as well as create surveys, invite businesses to create their own surveys, and give permissions as to who can answer a survey [1.] and then save the completed survey ID on-chain as proof of completion [1.] these transactions take place within our new UI [2.]
+| 1. | Survey pallet | We will create a Substrate module that will allow users to complete a survey, earn a zero knowledge proof upon completion and then connect their Polkadot JS wallet in order to withdraw the pre-defined reward amount by interacting with the pallet.
+| 2. | Survey pallet | We will create a Substrate module that will allow business to create a survey and then connect their Polkadot JS wallet in order to fund the pallet for respondents.
+| 3. | Survey pallet UI | We will create a new UI for DOT users to be able to connect their Polkadot JS wallet, interact with the pallet to withdraw or fund survey rewards and mint their respective NFT media onto a local substrate chain.
+| 4. | Substrate chain | The survey pallet of our custom chain will interact in such a way to allow users to connect their DOT wallet to our application, withdraw DOT and then mint media on a local substrate chain [1.] and these transactions take place within our new UI [3.] with proof recorded by our ZKP [5] after being funded by the business [2] and recorded in the data wallet [6]
+| 5. | ZKP Proof Generation | We will create an API for the Cubby data wallet to generate zero knowledge proofs upon survey completion on the Substrate chain - this ZKP will be the "receipt" to verify users are eligible to connect their wallet and withdraw rewards from a particular survey contract.
+| 6. | Data Wallet | We will open source our data wallet which is an authorizathion layer within QSTN allowing users to interact and generate zero knowledge proofs upon survey completion on DOT - this wallet interacts with the pallets deployed by our local substrate node through our API.
...
-
## Future Plans
-- In the short term, we are competing in hackathons to better our understanding of Web3 products and services we can use to scale out the QSTN market research portal.
-
-Particularly, we will be participating in the Filecoin Sustainable Blockchain Summit Hackathon, Encode x Chainlink Hackathon and submitting for a couple accelerator programs which include VC pitching.
-
-In conjunction with our hacking and education, we will be testing our existing application privately with different companies ranging from Encode Club, Filecoin, Octopus Network, NEAR Protocol to Ocean Protocol.
-
-- Looking towards the future, we are excited to host our first NFT launch event on NEAR Protocol (October) and work with more traditional Web2 businesses in music, entertainment and market research to onboard the next million users into Web3
+- As QSTN, our major product milestones for the next 6 months include:
+1. Developing the Cubby Data Wallet, which will replace user profiles, enabling users to authorize data requests directly from a Chrome extension wallet. This feature enhances user control over their data and streamlines the authorization process.
+2. Creating the Cubby File Storing Platform, a decentralized storage solution powered by Filecoin. Users and businesses can securely store their files, with the owner holding the only decryption key, ensuring privacy and exclusive access.
+3. Collaborating with NYU, L'Oréal, and Estée Lauder to test and refine our platform by incentivizing their respective communities, helping us gather valuable insights and optimize our offerings.
+4. Expanding our clientele beyond web3 startups to include larger legacy brands and marketing agencies. Our goal is to establish QSTN as the "go-to" self-service marketing tool for a diverse range of businesses seeking innovative and effective solutions.
## Additional Information :heavy_plus_sign:
@@ -227,6 +275,6 @@ In conjunction with our hacking and education, we will be testing our existing a
Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:
-- Please request a private invite to our repo (https://github.com/qstn-ansr) for our existing prototype on NEAR Protocol
+- Please request a private invite to our repo ([https://github.com/qstn-ansr](https://github.com/QSTN-US) for our existing prototype on NEAR Protocol
- If there are any other teams who have already contributed (financially) to the project.
- NEAR Foundation (grants program)
diff --git a/applications/RegionX.md b/applications/RegionX.md
new file mode 100644
index 00000000000..93efb5d3a7c
--- /dev/null
+++ b/applications/RegionX.md
@@ -0,0 +1,281 @@
+# RegionX
+
+- **Team Name:** RegionX
+- **Payment Address:** 0x1e86CD18E4443B5f57b0133077954Cd84896964d (USDC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Please provide the following:
+
+- This project is named RegionX, with 'X' representing 'exchange,' as the project serves as a Region exchange.
+- RegionX is a marketplace and a set of tools for Coretime manipulation and data tracking, with the goal of making development on Polkadot faster, easier, more flexible, and, as an end result, cheaper.
+- RegionX is a project that builds upon the ideas presented in the Agile Coretime RFC. The project will be developed under the assumption that the functionality described in the RFC will be implemented within the Polkadot/Kusama ecosystem.
+ Given that the `pallet-broker` already exists, we will have the capability to undertake all the development outlined in this proposal.
+- Creating robust tooling and a market for Coretime can have a significant impact on the development that takes place on Polkadot. It will enable experiments and small personal projects to be deployed to Polkadot with minimal effort and cost.
+
+### Project Details
+
+This project, in its final phase, will have four cohesive components. These components are the following:
+1. Coretime UI
+2. Coretime Market
+3. Data Analytics
+4. Development Hub
+
+This proposal exclusively addresses the first two components, while information regarding the remaining components is available in the 'Future Plans' section below.
+
+The following sections describe only the components that will be developed for this grant.
+
+#### Coretime UI
+
+Considering that the entire project is built upon the ideas presented in the Agile Coretime RFC, users must be able to perform actions on their Coretime using RegionX. For this reason, we will provide the Coretime UI, which will simplify the management of regions. The following is a list of components we intend to incorporate into RegionX.
+
+- **Regions Dashboard** will serve as a central hub for users, allowing them to browse all of the regions they own. The regions will be presented as UI card components containing all relevant metadata and actions that users can perform on their region.
+
+
+ 
+
+
+- **Partitioning UI** will offer users a convenient method for splitting their region. The UI will visually represent the region as a timeline, highlighting all potential pivotal points available for partitioning.
+
+ The Partitioning UI visualizes the region as a timeline and divides it into the selected TIME UNIT. This allows the user to easily determine the pivot point.
+
+
+ 
+
+
+- **Interlacing UI** will also allow users to easily interlace the region they own. The user will have the option to specify the region core mask as a fraction.
+
+
+ 
+
+
+- **Naming Regions & Tasks**: Users will have the option to assign names to their regions and tasks, making it simple to differentiate them.
+
+- **Assignment UI** will make it straightforward for users to allocate a task to their owned regions. The UI will display a dropdown menu containing all the tasks that the user has published to the relay chain, simplifying the selection process.
+
+
+ 
+
+
+- **Transfer** UI will offer a straightforward modal for users to perform transfers.
+
+
+ 
+
+
+#### Secondary Market
+
+Coretime is a resource that goes to waste if not utilized during its intended time. When you purchase a core for a month, it means you can use a maximum of one core at any given moment during that specific time period. If the core is not utilized, the Coretime is essentially squandered.
+
+After buying Coretime during the bulk period, one may realize that the purchased Coretime is either too much or too little for the intended use. The secondary market assists these individuals and teams in rectifying their mistakes by enabling them to sell or buy more Coretime.
+
+Coretime can be partitioned and interlaced, meaning most of the Coretime on sale will hardly be the same. For this reason, we are going to utilize the order book model.
+
+The seller will need to specify the price for the entire region, and based on that, the contract will calculate the price of one bit, which is equivalent to 1/80th of the price of the entire region.
+
+This bit-based valuation means that the total value of the Coretime owned by the seller will decrease every time the smallest computation unit is not used. From here, we can conclude that the price of the region on sale is dynamic.
+
+**The steps of selling and buying Coretime:**
+
+1. A user decides to sell one of their regions.
+ - The user defines the price that they intend to sell the region for.
+ - The contract calculates the price per bit.
+2. Another user decides to buy some Coretime.
+ - They are browsing the market and have decided they want to buy a specific region.
+ - The user will have to pay the price for the region; however, this won't be the price of the entire region. The price will be defined by `remaining_smallest_units * price_per_unit`.
+3. The user pays the price, the seller receives the paid amount, and the buyer receives the region.
+
+If a user doesn't want to buy the entire region but only a part of it, the buyer will need to specify which parts of the region they want and provide the steps to create a region with the properties they desire. This way, the user pays only for the portion of the region they wish to acquire.
+We refer to this feature as **Region Derivation**. It will give buyers more options when purchasing Coretime, making it easier to meet their specific needs. This feature is not implemented as part of this milestone, but is part of our future plans.
+
+**Defining the price of Coretime**
+
+The price of Coretime will be highly influenced by supply and demand. Since we are constructing a market with an NFT order book model, users will have the authority to establish the price of the Coretime they intend to sell.
+
+Depending on whether the seller owns an entire core, only partitioned parts, or has it interlaced, the selling price of the Coretime will be affected.
+
+As mentioned earlier, we will determine the pricing of a region at a bit level. This approach proves particularly useful because it allows us to establish a pricing structure that decreases when Coretime is wasted.
+
+In situations where the buyer's instructions involve partitioning the region and performing interlacing on the partitioned region, we will determine the price based on the bit price of the resulting partitioned region.
+
+This approach allows us to easily calculate the price of the region the buyer intends to purchase, even in situations where the buyer requires multiple instructions to be executed on the region.
+
+**Formula to calculate the price when partitioning:**
+`price = bit_price * pivot_defined_as_bit`
+
+**Formula to calculate the price when interlacing:**
+`price = bit_price * active_bits`
+
+**Market Architecture**
+
+The Coretime marketplace can be implemented in four different ways, which include:
+
+1. Ink! smart contract
+2. Solidity smart contract
+3. Actor (Not yet implemented in Polkadot/Kusama)
+4. Parachain
+
+From these options, we've selected the Ink! smart contract as our initial approach. As the project evolves, we anticipate transitioning to either an actor or a separate parachain to access greater possibilities to improve our services.
+
+**Implementation Requirements**
+
+We came up with an implementation design that makes it possible to develop the market as an ink! smart contract located on a contracts parachain in the Polkadot/Kusama ecosystem.
+Our solution has very minimal and reasonable assumptions required to make this possible.
+
+Our sole assumption is that the concepts outlined in the Agile Coretime RFC are implemented in Polkadot/Kusama. We do not have any specific assumptions concerning the XCM configuration on the Coretime parachain to make this work. We only require that the Coretime parachain allows basic reserve transfers.
+
+**Region NFT Contract**
+
+To create a marketplace on a contracts parachain, we'll need an NFT region contract. We'll use the [Openbrush](https://openbrush.brushfam.io/) psp34 contract as a starting point for the code we develop.
+
+**Coretime Market UI**
+
+This section outlines the design of the Coretime market developed as part of this proposal. If additional relevant data is identified, we will expand upon the design.
+
+- The main market dashboard allows users to browse and filter, making it easier for them to find the region they are looking for.
+
+ Users will have the flexibility to choose a time unit for inputting values, which will serve as the basis for region filtering. The maximum time unit available will be a day, allowing users to input values using a calendar input field. For other durations, users can simply provide numeric input in a designated field.
+
+ The Core ownership field will be represented as a percentage range of the total Coretime ownership that the region has on a specific core.
+
+
+ 
+
+
+- The UI for performing cross-chain region transfers which will be utilized when transferring regions between the Coretime chain and the smart contract chain where RegionX is deployed, or vice versa.
+
+ 
+
+
+- The UI for selling regions will become accessible to users once they choose one of their regions from the Region Dashboard. Any region listed for sale must be located on the smart contract parachain where RegionX is situated. In situations where the region is on the Coretime chain, users should first utilize the Cross-Chain UI for transferring the region.
+
+ 
+
+
+### Ecosystem Fit
+
+RegionX will offer a Coretime market and a suite of tools, making it easy for teams to develop their projects on Polkadot or Kusama. This project will empower smaller teams by providing flexible options to purchase regions from the market.
+
+The xcRegion and Coretime market contracts are designed for use by future teams interested in developing Coretime-related projects.
+
+[Lastic](https://github.com/w3f/Grants-Program/pull/2008) is a project in the Polkadot ecosystem with similar goals to ours. However, we have already defined many of our future ideas, which they have not yet mentioned implementing into their project. We have also developed a feasible solution for creating a flexible Coretime market with a dynamic pricing model.
+Given that the contracts developed as part of this grant are intended for use by many future projects, we would like Lastic to consider utilizing these contracts. As briefly mentioned in the _Future Plans_ section, we are also in the process of designing an economic model to incentivize the use of the same Coretime market. We believe this can foster healthy competition.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Sergej Sakac
+- Oliver Lim
+
+### Contact
+
+- **Contact Name:** Sergej Sakac
+- **Contact Email:** sakacszergej@gmail.com
+- **Website:** https://regionx.tech
+
+### Legal Structure
+
+- **Registered Address:** Kanalska 7 Novi Sad Serbia
+- **Registered Legal Entity:** MASTER UNION LLC.
+
+### Team's experience
+
+Sergej is a member of the Polkadot Fellowship. He has been an external core contributor on substrate and polkadot for more than a year now. Sergej is also a recent Engineering alumni of the Polkadot Blockchain Academy (PBA) held in Berkeley.
+
+Sergej has previously worked on a project that applied for a W3F. The details of the project can be found [here](https://github.com/Szegoo/Grants-Program/blob/42b031052c16670685c65a409d91779d0069903a/applications/Dotflow.md).
+
+Oliver is a full stack blockchain developer who was involved in 3 projects granted by the Web3 Foundation. He worked with Sergej on [Dotflow](https://github.com/thedotflow).
+
+Some of the past projects Oliver has worked on are [fs-dapp](https://github.com/fair-squares/fs-dapp), [imbue-frontend](https://github.com/imbuenetwork/imbue-frontend), [dotflow](https://github.com/TheDotflow/dotflow-ui)
+
+### Team Code Repos
+
+Github organization: https://github.com/RegionX-Labs
+
+Github profiles of team mebers:
+
+- https://github.com/Szegoo
+- https://github.com/cuteolaf
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/sergej-sakac-334a47252
+- https://www.linkedin.com/in/cuteolaf
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 4 months
+- **FTE:** 2
+- **Total Costs:** 30,000 USD
+
+### Milestone 1 - Coretime UI & xcRegions
+
+- **Estimated duration:** 1 month
+- **FTE:** 2
+- **Costs:** 12,000 USD
+
+| Number | Deliverable | Specification |
+| ------: | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **0a.** | License | GPLv3 |
+| **0b.** | Documentation | We will create documentation that thoroughly explains all aspects of the UI. Our goal is to design the UI to be as intuitive as possible, so users require minimal familiarization with the project. |
+| **0c.** | Testing and Testing Guide | All interactions with the Coretime parachain will undergo comprehensive testing to guarantee a seamless experience for users when using the RegionX UI. We will be running a local Zombienet network to simulate the existence of a Coretime parachain. |
+| **0d.** | Docker | We will provide a Dockerfile that will set up and run the RegionX Coretime UI. |
+| 0e. | Article | We'll compose a Medium article to explain the UI abstractions we've introduced around Coretime, offering insights into the capabilities achievable through the utilization of the Coretime UI. |
+| 1. | Mock Coretime Parachain runtime | We will establish a parachain dedicated to testing the Coretime abstractions and all future milestones. Essentially, this involves creating a parachain runtime that implements the `pallet-broker`. This parachain will simulate the Coretime chain. |
+| 2. | Simulated Local Network | Using the mock Coretime parachain, we will create a local Zombienet network consisting of a relay chain, Coretime chain, and a smart contract chain for the Coretime market. |
+| 3. | Coretime UI | We will implement all the sections and components described in the _Coretime UI_ section above. To summarize, this will consist of the following components: region dashboard, partitioning UI, interlacing UI, naming regions & tasks components, assignment UI and transfer UI |
+| 4. | Cross-chain Regions | As described in the previous sections, we will create an ink! smart contract that will be representing regions on the contracts parachain where we choose to deploy RegionX. This essentially means that users will have the capability to transfer their regions from the Coretime chain to another parachain. This NFT contract will be expanded to include the option for the region owner to initially set the region's end. The contract will perform certain sanity checks, although it's important to note that the accuracy of this information is not guaranteed. The UI client will be responsible for ensuring the correctness of this information when querying the region. |
+| 5. | xcRegion developer documentation | We will create documentation to explain how to easily integrate the xcRegion contract developed in this milestone. Our goal is to enable many teams in the future to integrate the contracts that are developed as part of this proposal. |
+
+### Milestone 2 - xcRegions UI & Coretime market contract
+
+- **Estimated duration:** 1.5 month
+- **FTE:** 2
+- **Costs:** 18,000 USD
+
+| Number | Deliverable | Specification |
+| ------: | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **0a.** | License | GPLv3 |
+| **0b.** | Documentation | The ink! smart contract will be well-written and documented. We will also create documentation that thoroughly explains all aspects of the UI. Our goal is to design the UI to be as intuitive as possible, so users require minimal familiarization with the project. |
+| **0c.** | Testing and Testing Guide | The ink! smart contract will undergo thorough testing, including e2e testing with a simulated zombienet network, to ensure maximum correctness. All UI interactions will undergo comprehensive testing to guarantee a seamless experience for users when using the RegionX UI. |
+| **0d.** | Docker | We will provide Dockerfiles for the ink! smart contracts that will set up the environment and execute the contract tests. Additionally, we will offer a Dockerfile that will configure and run the RegionX UI. |
+| 0e. | Article | We will compose a Medium article to offer a high-level explanation of the project's architecture. Within this article, we will clarify the significance of cross-chain region transfers and their crucial role in the Coretime market. |
+| 1. | Cross-chain Transfer UI | We will create the UI for transferring the region NFTs from the Coretime parachain to the contracts parachain and vice versa. |
+| 2. | Coretime Market Dashboard UI | In this milestone, we will also develop the Coretime Market dashboard UI. This section will be similar to the 'My Regions' dashboard, with the difference that it will display all the valid regions from the market instead of the regions owned by the user. Additionally, it will provide users with relevant information such as the cost of each region. The UI will also provide the option to buy or sell a region on the market. |
+| 3. | Coretime Market contract | We will develop the Coretime market as an ink! smart contract, as described above in the _Secondary Market_ section. This contract will use the xcRegions contract developed in the previous milestone. It will introduce listing functionality, enabling sellers to set the price for their regions. The contract will implement a bit-level pricing model, which will gradually reduce the cost of regions over time as the region remains unused. When a buyer acquires a listed region, they will only be charged for the Coretime they are going to receive thanks to the dynamic pricing model. |
+| 4. | Coretime Market developer documentation | We will create documentation to explain how to easily integrate the market contract developed in this milestone. Our goal is to enable many teams in the future to integrate the contracts that are developed as part of this proposal. |
+
+## Future Plans
+
+As mentioned at the beginning of the project details, this project consists of two other parts that are not developed as part of this application. The next describes the future plans categorized into these components.
+
+### Coretime Market
+
+As mentioned in the proposal we intend to further implement the **Region Derivation** feature. This will allow users to buy only a portion of the region that is being listed on sale.
+
+We also plan to finish the Coretime market UI, which will include more user-friendly region search and the ability to purchase portions of listed regions directly through the UI.
+
+Our plan is to have the market contract used by many other projects in the future. Since it would be highly beneficial for greater liquidity to utilize the same contract and not have many deployed, we plan to incorporate an economic model that incentivizes each of the projects using the same Coretime market contract.
+
+In the future, we also plan to transition from an Ink! contract to a parachain. This will provide us with greater flexibility over XCM, improved performance, and the possibility to more easily integrate with other pallets. Thanks to the greater flexibility on the parachain runtime side, in comparison to a contract, we have the potential to add a totally new way of buying Coretime. This would be possible by enabling users to pool funds, pre-define the ownership, and directly purchase a region from the Bulk market.
+
+### Data Analytics
+
+This component will provide users with the relevant information they need to better understand the Coretime market, empowering them to make informed decisions when buying or selling Cores.
+
+One of the pieces of data that will be displayed here is Coretime utilization. As a small prior experiment, we have created the following website that tracks the weight utilization from its maximum potential of each Polkadot and Kusama parachain: https://polkadot-weigher.com [twitter post](https://x.com/SakacSergej/status/1714270223489245505?s=20)
+
+### Developer Hub
+
+The developer hub will assist teams that have deployed tasks on Polkadot or Kusama in understanding their Coretime usage better. This is accomplished by providing a service of tracking Coretime consumption over time and presenting the data in graph form for the team.
+In the developer hub, users can register custom KPIs and use built-in ones. By utilizing KPIs along with previous months' data, we could potentially create an advisor to suggest the ideal Coretime allocation.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** GitHub
diff --git a/applications/Security_Marketplace.md b/applications/Security_Marketplace.md
index 95c73cd7155..b512238cc51 100644
--- a/applications/Security_Marketplace.md
+++ b/applications/Security_Marketplace.md
@@ -5,7 +5,7 @@
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
## Project Overview :page_facing_up:
-The proposal is in response to the RFP : [Decentralised Security marketplace](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/decentralized-security-marketplace.md).
+The proposal is in response to the RFP : [Decentralised Security marketplace](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/decentralized-security-marketplace.md).
### Overview
diff --git a/applications/SpellRouter-proposal.md b/applications/SpellRouter-proposal.md
new file mode 100644
index 00000000000..bedba935c46
--- /dev/null
+++ b/applications/SpellRouter-proposal.md
@@ -0,0 +1,302 @@
+# SpellRouter - XCM Router by ParaSpell✨
+
+- **Team Name:** ParaSpell✨
+- **Payment Address:** FIAT (Shared 22.Dec.2023 14:56 via contact email mentioned in the application)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 🐤
+
+## Project Overview :page_facing_up:
+
+Previously completed grants:
+- [Phase 1](https://github.com/w3f/Grants-Program/pull/1118)
+- [Phase 2](https://github.com/w3f/Grants-Program/pull/1245)
+- [Phase 3](https://github.com/w3f/Grants-Program/pull/1589)
+- [LightSpell](https://github.com/w3f/Grants-Program/pull/1817)
+
+**What we do focus on in ParaSpell✨:**
+
+Our team has focused on the unification of cross-chain communication in the Polkadot and Kusama ecosystems for a while now. Our latest and flagship addition is XCM API also known as LightSpell⚡️. This tool allows you to implement cross-chain interoperability into your application within moments. ParaSpell offers a set of XCM & XCMP Developer tools meant to ease the integration of cross-chain functionality into dApps. As we have learnt by now, cross-chain experience between Parachains can be very diverse. ParaSpell means to unify this experience by doing all the research for developers. We have wrapped all XCM pallets from compatible nodes into simple patterns from which it is easy to create XCM calls. As an example, we provide the image below.
+
+
+
+In this image, we can see, that ParaSpell XCM SDK saves much time for developers. Just one call can contain multiple lines of JSON which would otherwise have to be integrated manually by the developer. ParaSpell does it in marginally fewer lines and hides the complex logic of building messages which ensures, that messages are constructed correctly. This call in the end results in the following lengthy extrinsic:
+
+
+
+This extrinsic can be subscribed to for useful data in front-end applications.
+
+The same call can also be reproduced with the latest addition to our tool pack - XCM API. See the example below.
+
+
+
+### Overview 🎨
+
+ParaSpell is currently split into three main repositories at the moment. XCM Router, XCM API and XCM SDK will be merged into one monorepo package with the intention of sharing types and saving code:
+
+- XCM ROUTER - TBA: Meant to give developers the ability to exchange and transfer assets in one call in a seamless way that allows them to lift complexity from users.
+- [XCM SDK](https://github.com/paraspell/xcm-sdk): Meant to unify cross-chain experience on Polkadot and become a layer 2 protocol that allows for seamless integration of XCM into your dApps.
+- [XCM API](https://github.com/paraspell/xcm-api): Meant to ease the integration of XCM interoperability into your dApp, offload your dApp from heavy computing and save you costs.
+- [Docs](https://github.com/paraspell/docs): Extensive documentation for an overview of ParaSpell, a guide for SDK and API
+
+#### XCM SDK
+
+Few facts about XCM SDK:
+- The core component for XCM API
+- Comprehensive unification of XCM from 43 different Parachains
+- Allows for creating XCM calls with one-line
+- Simple to implement typescript package
+- Completely free with an MIT license
+
+XCM SDK allows developers to use XCM in all three available scenarios:
+- Parachain to Parachain - HRMP
+- Parachain to Relay chain - UMP
+- Relay chain to Parachain - DMP
+
+SDK contains many useful features that allow for easier integration:
+- Builder pattern implementation, easy to construct XCM calls, much more used recently for simplicity of implementation.
+
+- Suggestions, SDK contains TYPES that help to guide developers through integration. For example, they show compatible Parachains that can be used in calls.
+
+
+- Console printouts, SDK allows for printing into the console so developers can always check if the call they constructed is correct.
+
+
+- Exporting registered assets for each compatible node in many useful functions
+
+- Exporting supported XCM pallets for each compatible node in useful functions
+
+And more.
+
+#### XCM API
+XCM API currently supports 43 (this number changes a lot) XCM-compatible Parachains. It brings lots of advantages for developers.
+The advantages of LightSpell⚡️ XCM API for developers:
+- Provides the same functionality as XCM SDK with many benefits
+- Built-in user error prevention for seamless operation
+- Built-in Token authentication for DDoS prevention
+- Easy to use tech stack: Typescript, Nest.js, ParaSpell XCM-SDK
+- Completely free with an MIT license
+- Also designed for simple private deploy
+- API Offloads your server from heavy computing required to construct calls (You receive constructed message already)
+- API saves you server costs (Because of the reason mentioned above)
+- API features Package-less integration (No need to install anything compared to SDK alternatives)
+- API is simple to implement (Constructed to be as dev-friendly as possible)
+- API is already live on the following link: https://api.lightspell.xyz
+
+#### Docs
+Meet our comprehensive docs covering just about every topic developers will meet with when implementing XCM and our tools into their dAPPs.
+
+
+
+#### Architecture 🏗️
+##### Old
+The old design had SDK integrated into dApp:
+
+
+
+The replacement design with XCM API, there is no need for integrating XCM SDK. There is only a need to send the request. No more installing packages. Works way faster and offloads dApp from heavy computing to generate calls.
+
+
+
+##### New
+The newest architecture is similar to the one before it, however, dApps will now be able to call XCM Router through XCM API or integrate it as an independent package. XCM Router will benefit users with ease of exchanging and transferring assets to another chain as well as developers who can hide complex logic from users and integrate this feature with ease without the need for extensive research.
+
+
+
+This architecture is only proof of concept architecture. The final architecture may differ a little (Mostly because we want to make this as efficient as possible so if we find a better solution we will instead resort to it.
+#### Technology Stack 💻️
+- Vue.js
+- Node.js
+- Typescript
+- Polkadot API libraries
+- Nest.js
+
+### Ecosystem Fit 🌳
+
+#### XCM Router
+We strive to bring state-of-the-art technology to the ecosystem with any bright idea we get. SpellRouter XCM Router is no different. The implementation would become the first XCM Router in the Polkadot ecosystem.
+
+We aim to achieve XCM Router functionality by building a sovereign typescript package (for those who wish to implement it as a package) that will also be implemented in LightSpell XCM API (for those implementing LightSpell XCM API already). The core component for generating XCM calls will be ParaSpell XCM SDK. Other functionality regarding exchanges and logic will be unique to the Router itself. The XCM router will serve ecosystem users to transfer their assets cross-chain while giving them the ability to exchange them into different assets all in just one call (3 signatures). There were numerous suggestions for this tool in the ecosystem. Mainly because it brings the following benefits:
+
+- Ability to transfer assets cross-chain via XCM while being able to exchange them for another asset all within one call.
+- Offlift users from the complexity of moving assets to another chain in order to exchange tokens just to send them to another chain later
+- Developers able to hide asset exchange complexity and skip multiple implementation steps
+- Developers save the time required for complex research
+- Complex logic hidden in simple one-line calls
+
+An example of a Router call can be seen below:
+
+
+The choice of exchange Parachain will be automatic in a later version of XCM Router so users will only have to select exchange Parachain manually if they wish to.
+
+A high overview of Router functionality can be seen below:
+
+
+
+
+#### XCM API
+As mentioned in a tweet from Alice&Bob, we need Chain APIs to put XCM on steroids - [link](https://twitter.com/alice_und_bob/status/1664564442456109057?cxt=HHwWgsC9pdGi3JkuAAAA).
+
+We aim to achieve this by utilizing the XCM-SDK technology we built previously.
+Using XCM API compared to implementing XCM SDK into dApp can bring three main benefits:
+- Calls are generated much quicker
+- API is much simpler to implement than SDK
+- No need to install anything (Comes with the benefit of saving space and without issues with dependencies)
+
+Why we chose NestJS for XCM API:
+By choosing Nest.js as our backend HTTP REST API framework, we can harness the power of Node.js, leverage TypeScript's benefits, ensure maintainability through its modular architecture, and take advantage of its extensive community support. This enabled us to build a reliable, scalable, and well-documented XCM API that seamlessly integrates with the existing XCM SDK. In addition, Nest.js offers a powerful code generation feature that allows us to quickly scaffold boilerplate code for controllers, services, modules, and more. By utilizing the Nest.js code generator, we can significantly reduce development time and effort, ensuring rapid prototyping and efficient implementation of the XCM API endpoints. Compared to other TypeScript frameworks, Nest.js stands out with its modular architecture, seamless integration with Node.js, and strong community support, offering developers a scalable and maintainable solution.
+
+As API is now fully implemented we can observe its metrics for the first month it is deployed:
+
+
+We can see, that API serves between 500 to 1000 requests in a day. API uptime is 100%. API is completely free for everyone to use, implement or privately deploy.
+It now features various error prevention mechanisms (Valid wallet address check) and analytic tools to report errors that are not handled by API or report API usage (Strictly without collecting any sensitive user data).
+
+#### XCM SDK
+
+There are not many XCM & XCMP-related development tools released currently. We aim to aid this mostly empty space and help developers understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a set of tools which help them do development tasks more easily and faster.
+
+In Polkadot and Kusama ecosystems, there are few XCM-related tools in development. For example, Moonbeam XCM SDK and Parity Asset Transfer API. We bring a comparison table that compares them to our ParaSpell XCM SDK.
+| Features | ParaSpell XCM SDK | Moonbeam XCM SDK | Parity Asset Transfer API|
+| -----: | ----------- | ------------- | -----------|
+|UMP Support|Implemented|Implemented|Implemented (only for 2 Chains)|
+|DMP Support|Implemented|Implemented|Implemented (only for 2 Chains)|
+|HRMP Support|Implemented|Implemented|To be implemented|
+|No. of chains implemented|45 incl. Relay chains (To change to more chains with next update)|42 incl. Relay chains|4 incl. Relay chains|
+|Support for NFT transfers|Planned to be implemented|Not implemented| Planned to be implemented|
+|Multi-asset transfer support|Planned to be implemented|Not implemented|Planned to be implemented|
+|Multi-location specification|Automatic|Automatic|Required in some scenarios|
+| Build pattern | Integrated as intuitive as possible | Integrated, not as intuitive to implement however | Only function style call construction|
+| Support for asset pallet operations | Integrated | Not integrated | Not integrated|
+| Support for HRMP Channel operations | Integrated users can open & close HRMP channels on their local chain (Useful feature for devs) | Not integrated | Not integrated|
+| Support for checking details that do not change | Integrated & also be covered with some error handling eg (too little amount being sent, not sufficient for XCM transfer) | Integrated in the form of a small "map" for different Tokens & Node IDs | Integrated in form of Map|
+
+We are currently in talks with several Parachain teams that like the idea of unified SDK for XCM transfers as much as we do. SDK that unifies XCM can be very helpful for the entire ecosystem in our opinion. With the introduction of XCM API and soon XCM Router this improves even further.
+
+Our target audiences are Web3 projects and starting/current blockchain developers.
+
+As SDK is also fully developed and its metrics are available to the public we can see, that it is still used a lot by developers in the ecosystem (Even after the API release).
+
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+Dušan Morháč - Student, project Founder & Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava
+
+Michael Absolon - Student, XCM SDK & XCM API Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava
+
+### Contact
+
+- **Contact Name:** Dušan Morháč
+- **Contact Email:** dudo.morhac@gmail.com
+
+
+### Legal Structure
+
+- **Registered Address:** Tomášovská 453/2 Kalinovo 98501 Slovakia
+- **Registered Legal Entity:** Adam Morháč
+
+### Team's experience
+- Dušan is the founder & researcher behind this project and he has successfully presented it at the international conference ICECET2022 held in Prague from which there is an article regarding the XCMP & ParaSpell project. It is published by IEEE - [link](https://ieeexplore.ieee.org/document/9872938). He also successfully presented it at the ICBC 2023 conference held in Dubai. The article was published in [IEEE Enhancing XCMP Interoperability Across Polkadot Paraverse | IEEE Conference Publication](https://ieeexplore.ieee.org/document/10174872). Dušan studies Blockchain technology and had a bachelor's thesis about cross-blockchain sharing from which this idea was born. Dušan continues research on this idea in his Master's thesis. He is actively working on [LightSpell and ParaSpell](https://github.com/paraspell) full-time & has also participated in other ecosystem projects. Recently he attended Polkadot Blockchain Academy 2023 in Buenos Aires which gave him a lot of insight into the ecosystem and he also graduated from the academy successfully. Here is the [NFT that was minted as a certificate by Parity](https://singular.app/collectibles/statemine/20/12).
+
+And here is a certificate in physical form:
+
+
+
+- Michael is a dedicated TypeScript developer with 2 years of full-time experience in the Web2 sphere. Michael's expertise in this field was further solidified in 2019 when he won first place in the Junior Internet Web competition for his online multiplayer game, which was written in JavaScript. In addition to his professional background, Michael also achieved a bachelor's degree in the same computer science University as Dušan and he is currently pursuing a master's degree which focuses on Blockchain. His passion for technology led him to explore Blockchain technology in his free time. He was recently offered the opportunity to work on ParaSpell XCM SDK & LightSpell XCM API with Dušan and he delivered many of the key features SDK & API now offer.
+### Team Code Repos
+
+- https://github.com/paraspell/xcm-api
+- https://github.com/paraspell/xcm-sdk
+- https://github.com/paraspell/docs
+
+### Team Github Profiles 🧑🎓
+
+- https://github.com/dudo50 Dušan Morháč
+- https://github.com/michaeldev5 Michael Absolon
+
+### Team LinkedIn Profiles 🧑🎓
+
+- https://www.linkedin.com/in/dudo50/
+- https://www.linkedin.com/in/michael--absolon/
+
+## Development Status :open_book:
+We are currently finishing maintenance tasks and issues that are open in XCM SDK, XCM API and Docs repositories. After that, we wish to shift our focus to the development of an XCM Router which we already have laid out the structure for and we have basic functionality laid into small steps that will help us achieve making this state-of-the-art technology.
+
+As there are no XCM Routers currently in the ecosystem, this challenging task motivates us to fill the gap once again (Just like with XCM API).
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 5 months
+- **Full-Time Equivalent (FTE):** 1 FTE
+- **Total Costs:** 22 000 USD
+
+### Milestone 1 - Create XCM Router and move all three tools into Monorepo
+
+- **Estimated duration:** 3 months ⌛️
+- **FTE:** 1
+- **Costs:** 12 000 USD 💰️
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | MIT |
+| 0b. | Documentation | We will provide both readme.md and official docs documentation |
+| 0c. | Testing and Testing Guide | Testing guide will be mentioned in official docs|
+| 0e. | Create Medium article about development of early Router | Add article covering early XCM Router version |
+| 1.a | Integrate early version of XCM Router I| This version will contain additional detail about exchange Parachain (XCM Router will not select exchange automatically yet, the developer has to select from a provided list). The first version will feature functions like patterns to create calls. [See an example of function pattern](https://paraspell.github.io/docs/sdk/xcmPallet.html#function-pattern-xcm-call-from-relay-chain-to-parachain) |
+| 1.b | Integrate early version of XCM Router II| Compared to the first version, this version will feature a Builder pattern to enhance the developer experience. [See an example of builder pattern](https://paraspell.github.io/docs/sdk/xcmPallet.html#builder-pattern-xcm-call-from-relay-chain-to-parachain) |
+| 2. | Update docs to cover early XCM Router version| Add comprehensive guide that covers usage of early XCM Router version|
+|3.|Create unit tests for XCM Router|Create unit tests for core features in XCM Router|
+
+### Milestone 2 - Enhance XCM Router and feature automatic tool updating
+
+- **Estimated duration:** 2.5 months ⌛️
+- **FTE:** 1
+- **Costs:** 10 000 USD 💰️
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | MIT |
+| 0b. | Documentation | We will provide both readme.md and official docs documentation |
+| 0c. | Testing and Testing Guide | Testing guide will be mentioned in official docs|
+| 0e. | Create Medium article about development of latest XCM Router | Add article covering new features & improvements brought with SpellRouter☄️ |
+| 1. | Integrate automatic exchange chain selection into XCM Router | Integrate automatic exchange chain selection into the router (If the user wishes they can manually insert it otherwise Router will select automatically). XCM Router will try to select an exchange with the best pool/price. To see the difference between automatic and manual selection feel free to see the [following image](https://user-images.githubusercontent.com/55763425/277431789-cc3892dc-4452-49e1-a201-19edbc6f20d8.png)|
+| 2. | Integrate XCM Router into LightSpell XCM API | Integrate core functionality of XCM Router into LightSpell XCM API |
+|3.a| Update unit tests for new XCM Router functionalities| Update unit tests for new XCM Router functionalities|
+|3.b| Create integration tests for XCM Router|Create integration tests for core features in XCM Router|
+|3.c| Update integration, unit and e2e tests for LightSpell XCM API| Add new integration,unit & e2e tests for core LightSpell XCM API XCM Router integration|
+| 4.a | Cover latest automatic exchange chain selection in XCM Router section (Docs) | Add comprehensive guide covering automatic selection in XCM Router section |
+| 4.b | Cover XCM Router integration in XCM API section (Docs) | Cover XCM Router integration in LightSpell XCM API Section |
+
+## Future Plans 🔭
+- We wish to implement XCM v3 NFT transfer support
+- Once XCMP is out, we deprecate HRMP in SDK in favour of it.
+- Continue shaping XCM API to be as developer-friendly as possible
+- Continue gaining project integrations
+- Make sure XCM API uptime is nearing 100% and API works as should at all times
+- Improve XCM Router and add new ways to simplify call constructions
+
+Our focus will always remain on developer experience as well as being open source, completely free, common good and helpful to others.
+Another future goal that we try to keep is to continue innovating in the XCM area - bringing new state-of-the-art tech.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Personal recommendation
+
+##### Project achievements in chronological order ⌛️
+
+- 📙 Article about the project created & presented at international conference ICECET2022 held in Prague (450 out of 1000+ articles accepted) Link to IEEE publication - [IEEE Sharing Fungible Assets Across Polkadot Paraverse](https://ieeexplore.ieee.org/document/9872938/)
+- 🥈 2nd Prize, Build an XCM-related Tool for Moonbeam - Polkadot North America Hackathon [Hackathon entry](https://devpost.com/software/polkachange-cross-blockchain-transfer-tool)
+- 🥉 3rd Prize, EVM+ DApp for aUSD yield - Polkadot North America Hackathon [Hackathon entry](https://devpost.com/software/polkachange-cross-blockchain-transfer-tool)
+- 🎈 Web 3 Foundation base grant [Application](https://github.com/w3f/Grants-Program/pull/1118), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/584)
+- 🐍 [Basilisk](https://bsx.fi/) treasury proposal 2 / 2 Approved [link](https://basilisk.subsquare.io/treasury/proposal/2), [link2](https://basilisk.subsquare.io/treasury/proposal/4)
+- 🔭 Web 3 Foundation phase 2 grant Milestone 3 / 3 delivered [Application](https://github.com/w3f/Grants-Program/pull/1245), [Delivery1](https://github.com/w3f/Grant-Milestone-Delivery/pull/670), [Delivery 2 & 3](https://github.com/w3f/Grant-Milestone-Delivery/pull/715)
+- 📕 Article about Polkadot & ParaSpell created & accepted to be presented at international cross-chain conference IEEE ICBC 2023 held in Dubai - [IEEE Enhancing XCMP Interoperability Across Polkadot Paraverse](https://ieeexplore.ieee.org/document/10174872)
+- 💼 Kusama Treasury Funding proposal number 1 - Upgrade SDK, [Application](https://kusama.subsquare.io/referenda/referendum/123s), [Delivery](https://docs.google.com/document/d/1lMY_8EtQ41IX7Zn9VIMAiG1k3oLYN0h_lVj8dWDwZ_k/edit?usp=sharing)
+- 🏗️ Web 3 Foundation phase 3 grant (Make SDK better) Milestone 1 / 1 delivered [Application](https://github.com/w3f/Grants-Program/pull/1589), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/836)
+- 📘 Article about Polkadot & ParaSpell created & accepted to be presented at international cross-chain conference IEEE BCCA 2023 held in Kuwait [links TBA]
+- 🥈 Second place at sponsored prices Polkadot Global Series APAC 2023 Hackathon: Build a Connected Contract With Moonbeam [Linkedin post announcement](https://www.linkedin.com/posts/angelhack_polkadothackathonapac-koreablockchainweek-activity-7097217757724758016-8pJ_?utm_source=share&utm_medium=member_desktop)
+- 🥇 First place at Polkadot Global Series APAC 2023 Hackathon Finale [Finalist announcement post](https://www.linkedin.com/posts/angelhack_polkadothackathonapac-koreablockchainweek-activity-7097217757724758016-8pJ_?utm_source=share&utm_medium=member_desktop), [Final result](https://drive.google.com/drive/folders/1YxFJ4NO9_mMyNsXoPKboFfYHwHM1AJHv?usp=sharing), [Final result announcement post](https://www.linkedin.com/posts/angelhack_polkadothackathonapac-activity-7108072292718428160-i1dr?utm_source=share&utm_medium=member_desktop)
+- 🚀 Web 3 Foundation phase 4 grant (Build XCM-API) Milestone 1 / 1 delivered [Application](https://github.com/w3f/Grants-Program/pull/1817), [Delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/972)
+- 👷♂️ Maintenance funded by Kusama treasury from October 2023 until February 2024 [Referenda link](https://kusama.polkassembly.io/referenda/277)
diff --git a/applications/Substrate_Move_System_Pallet_1.md b/applications/Substrate_Move_System_Pallet_1.md
index e34c007b033..98bf346a600 100644
--- a/applications/Substrate_Move_System_Pallet_1.md
+++ b/applications/Substrate_Move_System_Pallet_1.md
@@ -6,7 +6,7 @@
## Project Overview ****📄****
-This application is a response to the **[Move Smart Contract Pallet RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/move_smart_contract_pallet.md).**
+This application is a response to the **[Move Smart Contract Pallet RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/move_smart_contract_pallet.md).**
### Overview
@@ -131,7 +131,7 @@ As mentioned in the Teams section, Eiger already has extensive experience develo
## Development Status **📖**
-- This application is a direct response to [this RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/move_smart_contract_pallet.md)
+- This application is a direct response to [this RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/move_smart_contract_pallet.md)
- [Move language Github](https://github.com/move-language/move/tree/main/language)
- [Pontem MoveVM fork](https://github.com/pontem-network/sp-move-vm)
- [Pontem MoveVM system pallet](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm)
diff --git a/applications/Substrate_Move_System_Pallet_2.md b/applications/Substrate_Move_System_Pallet_2.md
index c245490415b..ff161929ebf 100644
--- a/applications/Substrate_Move_System_Pallet_2.md
+++ b/applications/Substrate_Move_System_Pallet_2.md
@@ -6,7 +6,7 @@
## Project Overview ****📄****
-This application is a response to **[Move Smart Contract Pallet RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/move_smart_contract_pallet.md)** and a follow-up to our [previous work](https://github.com/w3f/Grants-Program/pull/1769) on the RFP.
+This application is a response to **[Move Smart Contract Pallet RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/move_smart_contract_pallet.md)** and a follow-up to our [previous work](https://github.com/w3f/Grants-Program/pull/1769) on the RFP.
### Overview
@@ -126,7 +126,7 @@ As mentioned in the Teams section, Eiger already has extensive experience develo
## Development Status **📖**
-- This application is a direct response to [this RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/move_smart_contract_pallet.md)
+- This application is a direct response to [this RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/move_smart_contract_pallet.md)
- [Move language Github](https://github.com/move-language/move/tree/main/language)
- [Pontem MoveVM fork](https://github.com/pontem-network/sp-move-vm)
- [Pontem MoveVM system pallet](https://github.com/pontem-network/pontem/tree/master/pallets/sp-mvm)
diff --git a/applications/Syncra.md b/applications/Syncra.md
index 20f2ea99ba2..3764804ae1f 100644
--- a/applications/Syncra.md
+++ b/applications/Syncra.md
@@ -3,6 +3,7 @@
- **Team Name:** Syncra
- **Payment Address:** 15Geo1RfLLM1PmPsD4uggts1Ht5LrWUChBDruLPqt5EgFKPB (PolkaDOT - USDT)
- **Level:** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1762#issuecomment-1769273868)
## Project Overview
@@ -286,4 +287,4 @@ Web3 Foundation Website, and Personal Recommendation.
### Previous grants you may have applied for
-- Aleph Zero Grants program
\ No newline at end of file
+- Aleph Zero Grants program
diff --git a/applications/TPScore.md b/applications/TPScore.md
index 6951775c1ab..10a9be37f16 100644
--- a/applications/TPScore.md
+++ b/applications/TPScore.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-This application is in response to the RFP [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/data_analysis_tools.md)
+This application is in response to the RFP [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md)
### Overview
@@ -117,7 +117,7 @@ As of the time of this application, no tools exist for checking TPS across the P
## Development Status :open_book:
-This project is a response to RFP [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/data_analysis_tools.md)
+This project is a response to RFP [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md)
Up until now, our primary focus has revolved around two key objectives:
1. Finding product-market fit
diff --git a/applications/Tellor.md b/applications/Tellor.md
index 51ec98a776a..b21734eb7db 100644
--- a/applications/Tellor.md
+++ b/applications/Tellor.md
@@ -3,6 +3,7 @@
- **Team Name:** Tellor Inc
- **Payment Address:** Ethereum 0x1B8E06E7133B89ea5A799Bf2bF0221aE71959190 (USDC)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1532#issuecomment-1781959568)
## Project Overview :page_facing_up:
@@ -225,4 +226,4 @@ You can find more information about the program [here](../README.md#moneybag-ref
**How did you hear about the Grants Program?**
-We talked to Rohan at a few events about building on Polkadot and he recommended we apply! We’ve been in touch with Robin Ejsmond-Frey, Frank Bell, and Guatam from Parity who have done significant work with us in developing the specifications and design for the build.
\ No newline at end of file
+We talked to Rohan at a few events about building on Polkadot and he recommended we apply! We’ve been in touch with Robin Ejsmond-Frey, Frank Bell, and Guatam from Parity who have done significant work with us in developing the specifications and design for the build.
diff --git a/applications/Tokenguard.md b/applications/Tokenguard.md
new file mode 100644
index 00000000000..3a2beaae2c0
--- /dev/null
+++ b/applications/Tokenguard.md
@@ -0,0 +1,310 @@
+
+# Tokenguard: Ultimate growth & data analytics tool for Substrate
+
+
+
+* **Team Name:** [Tokenguard.io](http://tokenguard.io/) (Block Solutions Sp z o.o.)
+* **Payment Address:** 0xa86d1302695a5e915fc54f2a18200337eacad082 (Ethereum ERC20 USDT)
+* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+
+
+
+## Project Overview 📄
+
+
+
+This application is a response to the RFP by Keegan Quigley: [https://grants.web3.foundation/docs/RFPs/Under Development/analysis-website-and-data-platform](https://grants.web3.foundation/docs/RFPs/Under%20Development/analysis-website-and-data-platform).
+
+
+
+### Overview
+
+
+
+**Absence of a user-friendly on-chain analytics platform** is an existing challenge of the Polkadot & Kusama ecosystems. Currently, querying data through GraphQL and backend services like Subquery and Subsquid requires considerable effort. Creating compelling and visually attractive dashboards is almost impossible due to lack of tools that focus on end user experinece. As a result, power-users and builders face difficulties in interactively accessing high-quality data and creating custom visualizations for easy sharing.
+
+
+
+
+
+To address this challenge, we propose an easy-to-use and efficient solution - an advanced data analytics tool designed to cater specifically to the needs of the Polkadot & Kusama ecosystems and related parachains. Our platform offers seamless data querying, simplifying the creation of customized charts and visualizations, **facilitating easy sharing of valuable insights and metrics within the** **community.**
+
+
+
+
+
+With the aim of ensuring extensive accessibility across the Substrate community and optimizing the functionality of our analytical tool, Tokenguard application places **a strong emphasis on refining the UX aspect**. This involves the development of an intuitive user interface (UI) and seamless frontend that effectively facilitates insights discovery.
+
+
+
+
+
+### Project Details
+
+
+
+To meet the expectations of Polkadot and Kusama community and the suggestions contained in the RFP, we propose a **comprehensive analytics tool consisting of** **a query builder, visualization creator and dashboard composer for Polkadot & Kusama ecosystems** - the creation of which requires the implementation of the following features.
+
+Features that will be built using this specific grant are **in bold**.
+
+1. Data model:
+ - Creating a RAW data access that would categorize data depending on its depth:
+ 1. L0: Relay chains (Polkadot, Kusama)
+ 2. L1: Parachains
+ 3. L2: dApps & Smart Contracts
+ - Creating a database of pre-transformed, comparable & curated metrics - each of the metric would be a pre-defined SQL query based on RAW data that is curated by Tokenguard team:
+ 1. User related metrics
+ 2. Activity related metrics
+ 3. Conversions related metrics
+2. Metrics
+ - Creation:
+ 1. Allowing users to create their own SQL queries from scratch and save them.
+ 2. Allowing users to preview SQL query of each of the existing metrics at Tokenguard.
+ 3. Allowing users to copy, edit and save each of the existing metrics.
+ - Collection:
+ 1. List of projects on different depths (L0, L1, L2)
+ 2. List of RAW tables available for these projects
+ 3. List of comparable metrics for these projects
+3. **Dashboards**
+ - **Making it possible for people to create & share dashboards with their own metrics:**
+ 1. **Providing a description and schema of required API response. The response consists of all possible measures and dimensions for future visualization.**
+ 2. **Creating a frontend which allows user to select series of data for axis X and Y for visualization.**
+ 3. **Allowing user to select type of visualization for the data among 5 types (linechart, barchart, piechart, multiline chart, stacked barchart).**
+ 4. **Designing frontend to layout visualizations on canvas (using drag & drop or any other method that is more comfortable for the user).**
+ 5. **Saving dashboard related data on backend to allow frontend transform database metrics into attractive visualisations.**
+
+4. Users
+ - Creating a user subpage with a list of users' dashboards & metrics
+ - Displaying user stats
+
+
+
+
+
+### **Beta Version - existing Tokenguard features**
+
+
+
+(You can access public version of Tokenguard app at [app.tokenguard.io](http://app.tokenguard.io/))
+
+
+
+
+
+Over the course of six months, Tokenguard application was meticulously developed with the objective of creating a user-friendly analytics tool for the Substrate Ecosystem, without requiring any coding or SQL skills. Within this timeframe, we successfully produced a beta version of the app, which now offers essential on-chain analytics for various projects within the Polkadot ecosystem, such as Astar, Aleph Zero, Nodle and many others.
+
+
+
+
+
+#### **Features and designs:**
+
+Dashboards overview - The overview of currently indexed and supported parachains:
+
+
+Ecosystem metrics dashboards - The on-chain data is visually presented through charts that are categorized into the most significant and essential aspects:
+
+
+
+Filtering - The ability to sort data based on the most useful indicators:
+
+
+
+
+
+User activity analytics - A module that allows for an in-depth analysis of user behavior based on metrics such as DAU, MAU, retention or user segments:
+
+
+#### **Proposal mockups - new standalone features:**
+
+
+Dashboard creator - The drag and drop feature allows users to add metrics onto the dashboard:
+
+
+Layout composer - Allowing for an easy modification of the dashboard's layout:
+
+
+
+
+
+**Technology Stack:**
+
+* JavaScript, TypeScript, Python
+* SQL, dbt, Airflow
+* Kubernetes
+* SubSquid
+* BI analytics tools
+* Cloud hosting and scalable infrastructure
+
+
+
+### Other Proposals Comparison
+
+
+
+[RFP](https://grants.web3.foundation/docs/RFPs/Under%20Development/analysis-website-and-data-platform) has been partially addressed by other teams in the proposals [#1716](https://github.com/w3f/Grants-Program/pull/1716) [#1768](https://github.com/w3f/Grants-Program/pull/1768) [#1748](https://github.com/w3f/Grants-Program/pull/1748) [#1815](https://github.com/w3f/Grants-Program/pull/1815) and work is underway to solve it. Being aware of how wide and complex the area of data analysis is, in our solution, we wanted to refer to the issues and propose modules that have not yet been built, but will complement the ongoing work.
+
+Compared to the following, Tokenguard in this proposal provides both a user-friendly no-code dashboard composer and visualisation composer - which UX / UI is designed in an accessible way, reaching a wide audience.
+
+Features created in this proposal will support other data-related projects, making it easier for them to attract Polkadot & Kusama users:
+
+* [#1716](https://github.com/w3f/Grants-Program/pull/1716) - is an ETL tool that focuses on delivering the Polkadot ecosystem data to a wide audience using Google BigQuery service.
+
+* [#1768](https://github.com/w3f/Grants-Program/pull/1768) - is an ETL tool focused on deep account analytics challenges.
+
+* [#1748](https://github.com/w3f/Grants-Program/pull/1748) - is a data analytics tool that focuses on wallet profiling and tracking its investments and structure.
+
+* [#1815](https://github.com/w3f/Grants-Program/pull/1815) - is a low-level SQL query editor and vizualization creator dedicated for data engineers and developers.
+
+
+### Ecosystem Fit
+
+In order to facilitate growth, Substrate ecosystem needs a vast and thriving environment of developers creating parachains, dApps and smart contracts. Each parachain and each smart contract generates thousands of transactions that store important technical and business insights. Each new growing dApp, with its own marketing & growth strategy, **brings in new active users to the ecosystem and venture capital money**. These insights are currently hard to discover and the ecosystem needs infrastructure tools that would make it easy for management teams and developers to uncover them, similarly as it is done in EVM environment with tools like Dune Analytics or Tenderly.
+
+Tokenguard addresses the need of following audiences:
+
+
+**Community:**
+* Transparency & Credibility:
+ * Access to data and on-chain insights is the basis for a community driven blockchain.
+ * The ability to track and verify activity and growth in the parachains reinforces trust.
+* Investment:
+ * A tool that gives access to the **performance of individual dApps and DeFi allows for a better investment decisions.**
+ * A tool that gives access to the performance of individual dApps and DeFi** allows for a better assessment of the market situation in terms of investment.
+ * Insights into data on developer activity and TVL allows to attract additional community members who want to invest in the ecosystem.
+* Engagement:
+ * A well-informed community is more likely to be involved in the building programs on a given chain and in ongoing activities.
+ * **Access to insights allows the community to actively promote chain in social media**, at events and in ordinary media.
+
+**Relay chains, parachains and dApps teams:**
+
+
+* Marketing Improvements:
+ * Off-chain to on-chain data correlation provides a deeper understanding of the marketing and PR efforts that contribute to the network’s growth
+ * **Developer engagement tracking allows to identify strategies that encourage web3 creators** to build within the ecosystem.
+ * User segmentation and user behavior tracking allows to understand **which protocols and dApps generate the most usage in the network** and what type of user affects its growth.
+* More efficient Treasury Spending:
+ * Tracking the **inflow of new users through dApps and on-chain projects financed through treasury grants** of relay and parachains allows measuring spending success.
+ * Source of **reliable data to support discussion and decisions during treasury votings**.
+* Strengthening Operations & Security:
+ * Real-time monitoring and alerts enable the team to respond more effectively in the face of potential threats such as rug pulls.
+ * Thanks to access to on-chain insights, such as a TVL in DeFi or a Smart Contract creation per developer, Tokenguard helps understand how to better optimize the operations of parachains for individual entities.
+
+
+Tokenguard's public features and data are already being used by community users and projects like DotInsights ([https://dotinsights.subwallet.app/polkadot-report-q2-2023-en/](https://dotinsights.subwallet.app/polkadot-report-q2-2023-en/)):
+
+
+
+## Team 👥
+### Team members
+
+
+
+* Kamil Gorski - CEO ([https://www.linkedin.com/in/gorskikamil/](https://www.linkedin.com/in/gorskikamil/))
+* Jakub Rojek - CTO ([https://www.linkedin.com/in/jakub-rojek-dev/](https://www.linkedin.com/in/jakub-rojek-dev/))
+* Damian Rolek - CDO ([https://www.linkedin.com/in/damianrolek/](https://www.linkedin.com/in/damianrolek/))
+* Matt Saczewski - Business Development Manager ([https://www.linkedin.com/in/msaczewski/](https://www.linkedin.com/in/msaczewski/))
+* Jacob Piorecki - UI/UX Designer ([https://www.linkedin.com/in/jacobpiorecki/](https://www.linkedin.com/in/jacobpiorecki/))
+* Piotr Józefowicz - Backend Developer ([https://www.linkedin.com/in/piotr-jozefowicz-529669220/](https://www.linkedin.com/in/piotr-jozefowicz-529669220/))
+* Adam Król - Backend Developer ([https://www.linkedin.com/in/adam-król-7b3a831b6/](https://www.linkedin.com/in/adam-kr%C3%B3l-7b3a831b6/))
+* Krystian Trepczyński - Frontend Developer ([https://www.linkedin.com/in/krystiantrepczynski/](https://www.linkedin.com/in/krystiantrepczynski/))
+
+
+### Contact
+* **Contact Name:** Matt Saczewski
+* **Contact Email:** [matt@tokenguard.io](mailto:matt@tokenguard.io)
+* **Website:** [tokenguard.io](http://tokenguard.io/)
+
+
+
+### Legal Structure
+* **Registered Address:** Foksal 3/5 St., 00-366 Warsaw, Poland, EU VAT ID PL7252284130
+* **Registered Legal Entity:** Block Solutions Sp z o.o.
+
+### Team’s experience
+Tokenguard’s clients include Swiss Sygnum Bank, [Bitcoin.com](http://bitcoin.com/), Astar, Aleph Zero and many others recognizable brands. Each of cofounders has tremendous web3 experience - Damian was co-creating DeFi analytics platform Kasuria. Jacob was working at OpenLoyalty, helping web3 projects engage their users and Kamil created web3 security solutions, designing a security monitoring that served 30+ tokens.
+
+### Current Traction & Business Model ###
+Our current business model focuses on offering growth analytics solutions for parachains & dApps and allowed us to validate both product and services through collaborations with notable parachains such as Astar and Aleph Zero. We believe that **delivering free of charge community analytics will further enhance discovery of growth insights within the whole ecosystem**, allowing it to win the race for leading position in the web3 space.
+
+Teams we cooperate with appreciate our flexibility and user-oriented approach:
+
*Tokenguard is the missing part for Astar ecosystem. Its analytics and tracking capabilities provide us with the crucial insights needed to understand on-chain activity and user behavior, allowing us to make data-driven decisions and optimize our strategies like never before.*
**Maarten Henskens, Head of Foundation, Astar Network**
+
+
*We are happy to use Tokenguard, which offers Aleph Zero comprehensive on-chain user metrics and engagement data. Thanks to their analytics tool, we can make data-driven decisions and provide transparency to our community with easy-to-use dashboards.*
**Antoni Zolciak, CMO, Aleph Zero**
+
+### Team Code Repos
+* [https://github.com/tokenguardio](https://github.com/tokenguardio)
+
+
+## Development Status 📖
+Tokenguard is currently developing the following features:
+* Publicly accessible core analytics for Substrate communities, available at [https://app.tokenguard.io](https://app.tokenguard.io/)
+* Ecosystem Analytics for [Astar](https://astar.network/) - paying customers
+* Ecosystem Analytics for [Aleph Zero](https://alephzero.org/) - paying customers
+* Ink! dApp analytics for [AZero ID](https://azero.id/), [ArthSwap](https://app.arthswap.org/), [Panjea](https://panjea.io/), [Interlock](https://www.interlock.network/) and others
+* Partnership with [SubSquid](https://www.subsquid.io/)
+
+## Development Roadmap 🔩
+
+Having a lot of experience in building web3 products, our team is aware that there are many challenges behind building a fully functional analytics platform similar to Dune for an ecosystem as vast and diverse as Polkadot & Kusama. We acknowledge the fact that a lot of questions need to be answered and W3F requirements need to be specified to fully estimate the cost of creating such a solution that will be **easily upgradable and basically - fun for users**. We therefore propose to split the work on the project into 3 composable grants / proposals:
+
+* Dashboard builder
+* Metrics creator & catalogue
+* Universal data model & ETL (work underway from other projects)
+
+This proposal is the first part that is solely focused on preparation of the dashboard creator, helping us and other teams deliver the data to users in an attractive form.
+
+
+### Overview
+* **Total Estimated Duration:** 2 months
+* **Full-Time Equivalent (FTE):** 1.5 FTE
+* **Total Costs:** 30,000 USD
+
+
+### Milestone 1: Frontend
+* **Estimated duration:** 2 months
+* **FTE:** 1.0
+* **Costs:** 20,000 USD
+
+
+
+| Number | Deliverable | Specification | TechStack |
+| ---| ---| --- | --- |
+|
**0a.**
| License | MIT | --- |
+|
**0b.**
| Documentation | We will provide inline documentation. | --- |
+|
**0c.**
| Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. 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.
| Metrics visualisation
| Allowing visualisation from RAW data:
1. Data selection interface for user including axis and scale setup,
2. Creating a preliminary visaulisation design standard of common data types,
3. Preparing 5 customisable visualisation types which include linechart, barchart, piechart, multiline chart, stacked barchart.
4. Creating a mechanism to customize the visualisations for differently branded projects | ReactJS, MongoDB, Apache ECharts |
+|
2.
| Dashboard layout | Creating a dashboard composer which allows:
1. Creating, saving, modifying and deleting new and existing dashboards,
2. Populating a dashboard with visualised metrics with drag & drop method,
3. Modifying the dashboard layout - changing the positions of charts, resizing and deleting them.
4. Enriching the dashboard with captions, titles and links. | ReactJS, React Grid Layout, MongoDB |
+
+
+
+### Milestone 2: Backend
+* **Estimated Duration:** 2 weeks
+* **FTE:** 1.5
+* **Costs:** 10,000 USD
+
+| Number | Deliverable | Specification | TechStack |
+| ---| ---| --- | --- |
+|
**0a.**
| License | MIT | --- |
+|
**0b.**
| Documentation | We will provide inline documentation. | --- |
+|
**0c.**
| Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. 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.
| API reading mechanism | Connecting frontend visualisations with underlying data through an API:
1. Description and schema for an API response,
2. Saving and modifying visualisation related data,
3. Saving and modifying dashboard related data,
4. Collecting user data in relation to dashboard and chosen metrics. | NodeJS, Express, OpenAPI, MongoDB |
+|
3.
| Report & estimation | Detailed report on the dashboard composer design and cost estimation of all the features mentioned in "Project details" as well as additional features requested by Web3 Foundation.| --- |
+
+
+
+
+## Future Plans
+### Analytics for Polkadot & Kusama ecosystems
+The module implemented under this proposal lays the foundation for covering the entire Polkadot & Kusama ecosystem with accessible and user-friendly tool for on-chain insights and analysis. PoC of query builder, visualization creator, dashboard composer for Polkadot and Kusama Relay Chains enables further scaling of the analytical tool to the entire ecosystem.
+
+The next steps will consist of a proposal to create a common dataset of metrics for each category of pallets/parachains; creating a more complex query builder, automated/semi-automated process of new parachain & dApp inclusion; automated/semi-automated process of user-requested tables aggregation; indexing and maintaining a database for the entire ecosystem (in cooperation with the Parity team).
+
+### Making web3 grow
+At the same time, continuing the current activities, Tokenguard will offer its services to provide custom dashboards with advanced features to subsequent parachains in order to improve their marketing and operational activities.
+
+With backing up of well-known web3 investors, Tokenguard is on its path to help web3 ecosystems and dApps understand their user behavior and focus on product & marketing strategies that deliver organic growth.
+
diff --git a/applications/TreasuryTracker.md b/applications/TreasuryTracker.md
index 372dfdbbb36..c9bd57cb470 100644
--- a/applications/TreasuryTracker.md
+++ b/applications/TreasuryTracker.md
@@ -75,7 +75,7 @@ The target audience for our platform includes token holders interested in the lo
While there are no projects in the ecosystem that address treasury components and provide the same level of analytics as our proposed platform, there are a few with related functionalities:
- [doTreasury](https://www.dotreasury.com/dot/) focuses solely on treasury statistics, lacking the wider analytical range that our project aims to offer
-- [Grant Management Web Application RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/grant_management_webapp.md) are focused on the W3F grants UI and are not including the analytics component our platform intends to deliver.
+- [Grant Management Web Application RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/grant_management_webapp.md) are focused on the W3F grants UI and are not including the analytics component our platform intends to deliver.
diff --git a/applications/TuxedoDapp.md b/applications/TuxedoDapp.md
new file mode 100644
index 00000000000..1a57fd2014a
--- /dev/null
+++ b/applications/TuxedoDapp.md
@@ -0,0 +1,260 @@
+# TuxedoDApp
+
+- **Team Name:** MLabs
+- **Payment Address:** FIAT
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+Develop a Tuxedo Web Wallet and DApp
+
+### Overview
+
+Unlike traditional account-based systems, UTXO-based systems treat each transaction output as a distinct entity, introducing advantages in parallel processing and state transition simplicity.
+The Tuxedo project endeavours to demonstrate the flexibility and interoperability of Polkadot by implementing UTXO as one of its paradigms. MLabs, with expertise in the Cardano ecosystem utilizing UTXO as its core model, sees an opportunity to contribute to Tuxedo's success, address identified issues, and engage in future collaborative activities.
+
+Our goal is to showcase the potential of Polkadot using the UTXO paradigm for the end user, leveraging Tuxedo. The project will consist of two key stages:
+
+- Stage 1: Developing a simple Web Wallet
+- Stage 2: Developing a basic DApp
+
+### Project Details
+
+- Stage 1: Developing a simple Web Wallet
+
+Develop a user-friendly web wallet that allows users to manage their UTXOs on the Tuxedo-based Polkadot network which is similar to polkadot.js which will get the chain info(genesisHash, runtime metadata, chain runtime version, API version), block info
+Focus on simplicity, security, and ease of use to provide a seamless experience for users interacting with UTXOs.
+
+**Technical Requirements**
+
+**Security:** : Private key storage:
+The web-based wallet will provide a secure method for private key storage on the client side, such as a browser's secure storage or hardware wallets.
+
+**Functionality**:
+1. Feature Parity Between Web-Based and CLI Wallets
+The web-based wallet will be designed to mirror the core functionality of the CLI wallet, offering seamless UTXO synchronization and token handling, ensuring that users have an equivalent experience across both interfaces
+Note: _Feature Parity_ means Means web-based and command-line interface (CLI) wallets, have the same set of features and functionalities, both versions provide an equivalent or identical user experience by offering the same core capabilities and options.
+
+2. Issues Fix in web-based wallet (https://github.com/Off-Narrative-Labs/Tuxedo/issues/62)
+The current implementation of a CLI-based wallet allows sending inputs from multiple owners in a single transaction, but it only supports a single recipient for all specified outputs.
+
+3. Browser compatibility:
+Web-based wallet will ensure compatibility with Chrome, Firefox and Edge.
+
+**Blockchain Integration**:
+Web-based wallet will connect to the blockchain node to fetch relevant data.
+We will check if there is any lib such as the one used by "https://polkadot.js.org/" to interact with the Tuxedo-based blockchain for easy integration.
+
+**Transactions**:
+web-based wallet will implement transaction creation and signing on the client side.
+We will consider using libraries that support the specific blockchain's transaction format for Tuxedo with UTXO instead of accounts.
+
+**Local Database**:
+web-based wallet will consider using databases for storing non-sensitive user data.
+Local database (e.g., IndexedDB, WebSQL, or a lightweight client-side database) to store relevant wallet data locally on the user's device.
+
+**Tech Stack**:
+- polkadot{.js} trying to re-use it if possible
+- React Framework(React + Redux + React Router) OR Vue Framework (Vue.js with Vuex and the Vue Router)
+- TypeScript
+- webpack
+- Babel for backward compatibility in older Browsers
+- IndexedDB for Local database
+- Jest as JavaScript testing framework
+
+Wallet Wireframes: [](https://drive.google.com/file/d/1nzE2_uqK5V4IwUJJPb92Q_WJk3RDR9UL/view?usp=sharing)
+
+- Stage 2: DApp Development
+
+Create a simple decentralized application to demonstrate the viability and maturity of the Tuxedo framework, as required by this opened ticket "Full Tuxedo App Implementation" https://github.com/Off-Narrative-Labs/Tuxedo/issues/76
+Showcase the unique features of UTXO-based transactions on Polkadot, emphasizing scalability and robustness.
+Address identified gaps and limitations in the current Tuxedo product to enhance overall functionality.
+We think that a successful showcase of a DApp is Cryptokitties which is provided in Tuxedo via pieces in "https://github.com/Off-Narrative-Labs/Tuxedo/tree/main/wardrobe/kitties".
+We want to use this concept and extend the wardrobe codebase by implementing a basic web interface and allowing breeding, trading, searching, and updating the kitty features such as name, price and tradable status of kitties.
+This DApp is intended for educational purposes only, and not for production use. The web wallet previously developed will be used for this DApp.
+
+**Technical Requirements**
+
+**Functionality**:
+Kitties Creation with NFTs:
+Represent each kitty as a unique NFT on the Tuxedo blockchain.
+Use Tuxedo runtime pieces i.e. kitties to handle NFT-based kitties creation transactions.
+
+**Breeding and NFT Ownership**:
+DApp ensures NFT ownership is transferred correctly during breeding transactions.
+Leverage NFT attributes to determine genetics and other breeding-related factors.
+
+**Trading of kitties between users**:
+DApp ensures Kitties can be traded between the users.
+Ensure ownership is transferred successfully once trading is completed.
+
+**Updating the kitty details**:
+DApp ensures Kittie's details such as name, tradable status(Yes or No) and Price can be updated.
+
+**Search kitties owned by other users**:
+DApp helps search the kitties other users own based on the user's public key.
+This displays the list of kitties owned by other users with all details required for trading such as Gender, Tradable status, Price, Parents, etc.
+
+**Blockchain Integration**:
+Tuxedo Runtime pieces.(wardrobe/kitties ):
+We need Leverage Tuxedo runtime pieces for implementing specific DApp functionalities in the UTXO model, with a focus on NFTs, if some modification is required or if some new functionality is required we may need to customize runtime logic to suit the requirements of the UTXO-based DApp.
+For this scope, we plan to modify the kitties' pieces code to support below features:
+
+1. Generating the kitty without the parent when the user inserts the new key in the wallet (basically, 1 kitty is provided for free as an onboarding process)
+2. Implementing the Trading of kitties between users
+3. Searching kitties owned by other users
+4. Adding/Updating more details of kitties such as Gender, Tradable status, Price, and Name.
+
+**Transaction Handling**:
+DApp implements transaction handling logic in the web application to initiate UTXO-based transactions, including NFT-related transactions, on the Tuxedo blockchain.
+Provide feedback to users on transaction status and confirmations.
+
+**Transaction Confirmation**:
+DApp implements a transaction confirmation mechanism to ensure that users are informed about the progress and finalization of UTXO and NFT-based transactions such as Trade and Breed.
+
+**Personal Dashboard**:
+We will develop a personal dashboard for users to view and manage their NFT-based Kitties collections.
+Display detailed information about each NFT, including ownership history and transaction history.
+Manage NFT means, it includes below :
+
+1. Viewing NFTs:
+ Users should be able to see a comprehensive list or visual representation of all the NFTs (kitties) they own.
+ Display detailed information about each NFT, including attributes such as below :
+ Name
+ parents(mom and dad)
+ free_breedings(numbers)
+ dna(H256 Hash value)
+ num_breedings(number)
+ Tradable(yes or No)
+ Price
+ Status (Ready for Raring, Tired (only for Dad), Had birth recently(only for Mom)).
+2. Trade :
+ Users should be able to buy the kitty from other users via the search kitty screen or directly from the Trade Kitty screen by inputting the kitty & owner details.
+3. Breed :
+ Users should be able to initiate breeding directly from the dashboard.
+4. Update :
+ Users should be able to update features such as Tradable status, price, and name from the dashboard by clicking on any cell which will navigate to update the kitty screen.
+5. Interactivity:
+ Make the dashboard interactive, allowing users to click on individual NFTs to access more detailed information or initiate specific actions.
+
+**Tech Stack:**
+- Polkadot-JS APIs for getting block data
+- React Framework(React + Redux + React Router) OR Vue Framework (Vue.js with Vuex and the Vue Router)
+- TypeScript
+- Babel for backward compatibility in older Browsers
+- IndexedDB for Local database
+- IPFS for storing metadata related to the kitty such as Name, Trade status, Price, etc.
+- Jest as JavaScript testing framework
+
+DApp Wireframes: [](https://drive.google.com/file/d/1dCr5Wwi0L-fGPdwAQGFPDhmTeBQYPDy1/view?usp=sharing)
+
+
+### Ecosystem Fit
+
+**Where and how does your project fit into the ecosystem?**
+
+- TuxedoDApp seeks to propel the Tuxedo project forward by addressing its current limitations and showcasing the capabilities of Polkadot with the UTXO paradigm. By developing a user-friendly web wallet and a simple DApp, we aim to provide a valuable use case for users of this ecosystem with limited experience in UTXO.
+
+**Who is your target audience?**
+
+- **Developers and Enthusiasts from other blockchains:** Developers interested in experimenting with another paradigm but also developers from other ecosystems more "bitcoin-based" that want to try Polkadot.
+
+- **New Learners in Blockchain Development:** Individuals who are new to blockchain development and want to learn by engaging with the Tuxedo framework. The Tuxedo Web Wallet and DApp can serve as educational tools, providing a practical environment for learners to understand and experiment with UTXO-based blockchain concepts.
+
+**Are there any other projects similar to yours in the Substrate/Polkadot/Kusama ecosystem?**
+
+- Tuxedo is unique and we are not aware of any DApp implemented as of today.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Mario Altimari
+- Amit Nadiger
+
+### Contact
+
+- **Contact Name:** Mario Altimari
+- **Contact Email:** marioaltimari@mlabs.city
+- **Website:** https://www.mlabs.city
+
+### Legal Structure
+
+- **Registered Address:** Address of your registered legal entity, if available. Please keep it in a single line. MLabs LTD, 1st-floor Citibase Millbank Tower,21-24 Millbank, LONDON SW1P 4QP, United Kingdom
+- **Registered Legal Entity:** MLabs LTD
+
+### Team's experience
+
+- Mario has witnessed the evolution of the web from its early days to the present, as an IT expert with more than two decades of experience. He has worked on various projects with different roles involving Web 1, Web 2 and Web 3 technologies, and has a deep understanding of the challenges and opportunities in each domain.
+- Amit is a seasoned software professional with over 18 years of extensive experience in the industry.
+His expertise spans a variety of programming languages, including C, C++, Java, Kotlin, and Rust, as well as diverse technologies such as Blockchain, Android app development, and AOSP (Android Open Source Project) development.
+In the blockchain space, Amit has showcased his proficiency in Pallet Development.
+He has successfully implemented advanced practices, including Prometheus and Grafana for metrics and telemetry, forkless upgrades of runtime, and pallets using polkadot.js.org.
+Additionally, Amit has hands-on experience in Ink-based SmartContract development and deployment using a web interface in Substrate Blockchain, demonstrating his versatility in running nodes with different roles, such as Validator/Author and Full node, and configuring Aura and Grandpa through chain specification updates in customSpec.json.
+His diverse skill set showcases a comprehensive understanding of blockchain technologies and their practical applications.
+Amit has more than 100 technical blogs in Blockchain specifically in Substrate, Polkadot and Rust language, Wasm: https://www.linkedin.com/pulse/consolidated-article-categorization-amit-nadiger/
+
+Nobody applied for a Web3 Foundation grant before.
+
+### Team Code Repos
+
+- Mario Altimari [https://github.com/AltiMario](https://github.com/AltiMario)
+- Amit Nadiger [https://github.com/NadigerAmit](https://github.com/NadigerAmit)
+
+### Team LinkedIn Profiles (if available)
+
+- Mario Altimari https://www.linkedin.com/in/altimario/
+- Amit Nadiger https://www.linkedin.com/in/amit-nadiger-94a7224/
+
+## Development Status :open_book:
+
+We have had conversations with the W3F team to validate the idea and find a starting point for collaboration
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 3 months
+- **Full-Time Equivalent (FTE):** 2 FTE
+- **Total Costs:** $24000 (USD)
+
+### Milestone 1 — Stage 1: Developing a simple Web Wallet
+
+- **Estimated duration:** 1 month
+- **FTE:** *1*
+- **Costs:** $10000 (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 use the web wallet app for Tuxedo (Private key configuration, local URI to be used to connect to blockchain) and send test transactions, tuxedo balance, which will show how the new functionality works. |
+| **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.** | Article | We will publish an **article**/workshop that explains how to use the web-based wallet which can be used to configure the user's private key and also get the information from the tuxedo based blockchain, how to do the transactions based on UTXO instead of account-based blockchain. |
+| **0e.** | Docker image containing any changes/issue fix in Tuxedo core | Will provide the docker image containing any changes or issue fix in Tuxedo core for wallet implementation |
+| **0f.** | Web-based wallet | We will create a web-based wallet that will have functionalities like Storing the private key of the user,(send and receive) Transaction support, all the functionalities provided by the CLI-based wallet (VerifyCoin, SpendCoins, InsertKey, GenerateKey, ShowKeys, RemoveKey, ShowBalance, ShowAllOutputs) |
+
+### Milestone 2 — Stage 2: Developing a basic DApp
+
+- **Estimated Duration:** 2 months
+- **FTE:** 2
+- **Costs:** $14000 (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 use the DApp app to breed kitties, view the kitties using the dashboard |
+| **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.** | Article | We will publish an **article**/workshop that explains how to use the DApp which can be used to "create the kitty as NFT", Breeding of kitties, and also how to use the Dashboard |
+| **0e.** | Kitties Pieces: Docker image |Docker image containing the kitties which support new features such as "Mint kitty without mom and dad, Trade kitty, change ownership of kitty and search kitties" |
+| **0f.** | DApp | We will create a web-based Daap to support functionality such as "create the kitty as NFT", managing the ownership of NFT/Kitties, Breeding, Trading kitties, and showing info (meaning of "Management of NFT" is mentioned above in Dashboard section ) |
+| **0g.** | Personalized Dashboard | We will create a personal dashboard for users to view and manage their NFT-based kitty collections. Display detailed information about each NFT, including ownership and other details such as parents, dna, Tradable status, Price, etc |
+
+## Future Plans
+
+**Dynamic Wallet**: Making the wallet dynamic by using a standard metadata format such in FRAME, between the wallet and the blockchain, so that any newly created pieces can be tested without extra modification. For this priority activity, we expect not less than 3 months of work with a budget estimation under $30k
+
+## Referral Program (optional) :moneybag:
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Meeting with the Web3 Foundation team at the beautiful Sub0 conference in Lisbon
diff --git a/applications/WeTEE_Network.md b/applications/WeTEE_Network.md
new file mode 100644
index 00000000000..a92d60e6fbd
--- /dev/null
+++ b/applications/WeTEE_Network.md
@@ -0,0 +1,310 @@
+# WeTEE Network
+
+- **Team Name:** WeTEE DAO
+- **Payment Address:** 13Zsmt8cKKVLWTBLHC68d6jNG5cpi7ghFPGgG35gmpwqaxrz(USDT)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+#### Background
+
+With the development of Web3, more and more applications will be directly deployed on chain, or partially store business data on chain.
+
+These applications mainly use a front-end / back-end separation architecture, that is, the applications consist of a user interface and a backend built by smart contracts. In theory, any type of application can run on a network with smart contract functionality, but at the same time, these applications also need to compromise for the relatively scarce computing resources on the decentralized network and the high latency in processing business data.
+
+
+
+On the other hand, Web2 has a vast number of applications and a mature technology architecture system. When application developers migrate their Web2 applications to Web3, they are faced with challenges such as addressing the compatibility problem between application and chain, handling application deployment issues, dealing with privacy concerns regarding application business data, and figuring out how to update applications to fix security vulnerabilities.
+
+In a nutshell, the familiar Web2 application development and deployment paradigms currently lack viable alternatives in the Web3 domain. This gap will likely hinder the emergence of Web3 applications and delay the progression of the Web3 application market.
+
+#### Current Problems
+
+- Web2 applications are typically deployed in a centralized manner, making business data prone to machine scanning.
+- After Web2 applications are adapted to smart contracts, there will be a significant performance overhead and they will face network congestion.
+- There is a risk of leakage of application business privacy data, resulting in financial losses for individuals and institutions.
+- Smart contracts have inherent limitations and face restrictions in supporting private data, GameFi, AI, metaverse, etc.
+- Web3 lacks software infrastructure similar to Web2, which cannot meet the diverse deployment requirements of Web3 applications.
+
+#### WeTEE Project
+
+WeTEE is a decentralized application deployment platform integrated with a Trusted Execution Environment (TEE).
+
+WeTEE consists of blockchain networks and multiple confidential computing clusters, collectively providing an efficient decentralised solution for confidential computing.
+
+Thread-level confidential container service providers need to provide hardware devices that support Intel SGX, and they are required to use IPv4 / IPv6 to access the Internet.
+
+1. At this stage, Substrate is mainly used as the blockchain framework to implement application deployment and billing-related smart contract functions.
+2. After the application is deployed, its workload will be safeguarded by hardware protection to prevent data leakage. Even confidential computing providers will not be able to access the data.
+3. It integrates with the existing cloud native toolchain for developers, typically requiring no code modifications, and in special cases, only a small amount of code modification is needed.
+4. Developers can view information such as the resource usage and health status of applications in the Web interface provided by WeTEE.
+
+#### WeTEE Solutions
+
+WeTEE's technological approach is an all-encompassing solution incorporating a number of leading-edge technologies, striving to deliver the most superior and secure services across all facets such as the hardware layer, encryption layer, application layer, data layer, and user layer. Its design perspective ranges from considering fundamental hardware compatibility to enhancing user experience on the front-end, demonstrating unique design considerations and processes, resulting in a solution that is not only dependable but also highly feasible in practice.
+
+
+
+1. **In the hardware layer:**
+ WeTEE utilizes K3S / K8S technology to abstract underlying hardware disparities, effectively isolating compatibility issues caused by hardware variances. Concurrently, by leveraging Intel SGX, it establishes a confidential computing environment, ensuring a sufficient level of security and trust for the application's hardware operating environment.
+2. **In the encryption layer:**
+ WeTEE fully capitalizes on the characteristics of TEE, establishing Worker nodes for confidential computations. These nodes can be deployed and validate confidential microservices on the original K3S / K8S, ensuring the system's security and scalability.
+3. **In the chain management layer:**
+ WeTEE builds a high-performance decentralized organizational account, decentralized finance, and on-chain confidential computing management function by using Substrate technology. This enables WeTEE to not only serve individual developers but also provide enterprise-level services for DAO organizations' applications.
+4. **In the application deployment layer:**
+ WeTEE integrates the K3S / K8S cloud-native tech stack, inheriting agile, stable, resilient, and easily scalable features. Such a framework makes it easier to deploy complex business applications, while also supporting their updates and iterations, aiming at further eliminating potential application vulnerabilities.
+5. **In the data management layer:**
+ WeTEE adopts the "TEE Confidential Injection" approach, generating encrypted replicas among the server nodes to prevent accidental data loss, thus ensuring the security of business data.
+6. **In terms of the user experience:**
+ WeTEE provides an intuitive Web UI interface, making it easy for application developers to deploy and monitor their applications.
+
+### Project Details
+
+#### Documentations
+
+- WeTEE Product PPT: [PPT Link](https://raw.githubusercontent.com/wetee-dao/chain/f01744e08489b3c9ac6c9c61c0c3cc3e396a3302/docs/deck/weteeBP%20(%20ENG%20).pdf)
+
+WeTEE has streamlined the development of blockchain applications, reduced the complexity of development, and expedited the transition from Web2 to Web3.
+
+Developers can leverage WeTEE to effortlessly implement the separation architecture between on-chain and off-chain applications at an extremely low cost, while maintaining the original business logic, making the integration and application of blockchain technology more accessible. Cutting-edge technologies such as intelligent compilation, hybrid operation, and data layering have been integrated into WeTEE, enabling it to effectively address the core issues of deploying applications in a blockchain environment.
+
+
+
+WeTEE allows developers to bypass the need for putting considerable time and energy into comprehending and conforming to blockchain technology, hence enabling them to swiftly concentrate on the essential function development of applications, significantly escalating development productivity.
+
+In the cryptocurrency world, data privacy has persistently been under the spotlight. The data privacy safeguarding mechanism utilized by WeTEE assures the security of user data throughout the computing and storing processes, ensuring user privacy rights, which brings about enhanced customers' trust in the product.
+
+Additionally, WeTEE adjusts the performance efficiency of both on-chain and off-chain operations to allow for faster transaction handling, thus delivering a smooth user experience and easing user interaction. Equally, WeTEE grants applications the ability for efficient iterations thereby better accommodating market variability and changes in user requirements, ensuring sustained competitive advantage for the application.
+
+WeTEE incorporates an intelligent compiler that possesses auto code analysis capabilities. This compiler can deeply parse the codes of Web2 applications and astutely identify the compilable sections related to business logic. WeTEE will extract these parts of code and automate its compilation into TEE application containers, improving application performance while ensuring security. The main features of the WeTEE intelligent compiler are as follows:
+
+
+
+1. **Backs Major Web Development Languages:**
+ Including but not limited to Rust, Go, JavaScript, Python, C, etc.
+2. **Code Analysis Support:**
+ Facilitates static and dynamic code analysis and extracts the compilable sections.
+3. **Auto Compilation:**
+ Compilable code runs through automatic compilation in accordance with pre-set WeTEE strategies, eliminating the need for manual intervention.
+4. **Code Compilation Log:**
+ Upon completion of compilation, a detailed log will be generated, allowing developers to review the compilation process.
+
+WeTEE establishes a hybrid runtime for applications, functioning as middleware to enable seamless interaction between Web2 frontend and on-chain smart contracts backend. The main features of WeTEE hybrid runtime include:
+
+1. **Simplified Off-Chain Interface Calls:**
+ Developers can easily facilitate off-chain calls through the interface, reducing interaction costs between the application and the chain.
+2. **Mapping of Business Logic On-Chain:**
+ In face of complex application business logic, WeTEE can automatically manage its on-chain execution mapping relationships.
+3. **Private Data Off-Chain Processing:**
+ When processing data involving privacy, WeTEE will utilize off-chain computing power within the platform for privacy computations.
+4. **Scalable Computing Power:**
+ The platform's off-chain computing power, used to handle compute-intensive tasks, can be expanded to compensate for any lack of on-chain computing power.
+5. **Chain Interaction Encapsulation:**
+ The hybrid runtime encapsulates the interaction logic with the chain, allowing frontend to interact with the chain transparently, reducing privacy data leakage.
+
+When an application is processed by the WeTEE intelligent compiler and operates successfully within the WeTEE platform, developers typically do not have to worry about the application's running status. Nevertheless, as an application deployment platform, WeTEE still provides customers with essential and accurate application link tracking and monitoring capabilities, as well as timely fault warning and diagnostic abilities, ensuring the healthy operation of applications. The primary features of WeTEE's automated monitoring include:
+
+
+
+1. **Resource Monitoring:**
+ Regular gathering and statistics of key metrics such as CPU load, memory usage, storage space utilization, etc.
+2. **Network Monitoring:**
+ Regular network status probes to perceive network changes.
+3. **Chain Status Monitoring:**
+ Regular monitoring and inspection of interactive data on the chain.
+4. **Application Health Monitoring:**
+ Regular monitoring of application response time, abnormal logs, and other metrics.
+5. **Anomaly Behavior Monitoring:**
+ Based on generic anomaly behavior monitoring models, evaluate application behavior and report abnormal behaviors.
+6. **Status Alert:**
+ Alerts will be triggered when the application's resource usage is about to exceed the threshold or when abnormal behaviors occur in the application.
+7. **Fault Review:**
+ When an application experiences abnormal operation or crashes, WeTEE can provide application logs and other data, aiding in fault review and diagnosis.
+
+When application developers need to update their applications to provide new features or security patches, they can fully leverage the hot update mechanism provided by WeTEE for rapid application updates. WeTEE's hot update mechanism adopts the common hot update solution for current cloud-native applications, and has the following main features:
+
+
+
+1. **Code Hot Update:**
+ After the application code is updated, it will be automatically compiled and pushed online, reducing application downtime.
+2. **Seamless Experience:**
+ The user side can be insensitive to application updates, improving user experience.
+3. **Development Paradigm:**
+ Compatible with and supports cloud-native development habits. Application developers can continue to use familiar tools and processes.
+4. **Change Flexibility:**
+ The hot update mechanism has extended the decentralized application update method, improving the adaptability and timeliness of the application.
+
+WeTEE deeply comprehends the potential challenges brought by decentralized application (DApp) development and deployment, and thus independently designs a feature to achieve seamless integration and easy deployment of DApps and Web2 applications. This feature not only automates many tedious operational tasks but also ensures the stability and efficiency of deployment. The key features of WeTEE's DApp one-click deployment function include:
+
+1. **One-click Deployment:**
+ With just a single operation, it can automatically deploy smart contracts on-chain and initiate off-chain services.
+2. **DApp SDK:**
+ Provides a smart contract SDK for application developers, enabling rapid communication between on-chain and off-chain.
+3. **Elastic Expansion:**
+ Equipped with the ability to sense application resource usage, it dynamically adjusts the application's resource quota according to preset policies.
+4. **Application Assurance:**
+ In the event of application failure detection, it will automatically handle the situation in accordance with the application emergency plan and attempt fault recovery.
+
+Currently, WeTEE's application management mechanism will use a democratic-centered governance mechanism similar to Polkadot OpenGov to govern the network.
+
+WeTEE replaces the board with DAO and uses a reputation voting system for on-chain decision-making, allowing more people to participate in the chain governance and thus promoting better community development. You can participate in or supervise the WeTEE project research and development, and alter chain parameters by voting.
+
+#### Technology Stack
+
+
+
+WeTEE implements a mainstream industry layered architecture design to accurately isolate on-chain and off-chain data, with a specific emphasis on optimizing the security storage strategy for off-chain data. The primary advantage of this layered architecture is its ability to determine the optimal storage and processing solutions for diverse types of data, guaranteeing data safety and privacy, and achieving efficient resource utilization and management.
+
+- **On-chain Core Data:**
+ Within this layered architecture, on-chain data primarily comprises essential transaction details and key state updates. With the non-alterable and decentralized characteristics of the blockchain, WeTEE ensures that all pertinent data is impeccably recorded on the blockchain, thereby enhancing the transparency of business processes in applications and offering key support to ensure data authenticity and completeness.
+- **Off-chain Data Encryption:**
+ Considering the storage needs of certain sensitive user data and a large amount of supplementary data, WeTEE has designed an encrypted storage solution for off-chain data. This encryption scheme employs hardware encryption techniques like Intel SGX / AMD SEV, ensuring that encrypted data retains integrity and offers error tolerance and recovery capabilities, significantly reducing the risk of data leakage.
+- **Data Access Control:**
+ Simultaneously, while sensitive data is encrypted, WeTEE also incorporates proof of data ownership and stringent data access control mechanisms. By utilizing refined data access control policies, unauthorized access can be effectively prevented, thereby further securing the safety of private data.
+
+Through the above design, WeTEE's layered architecture, using distributed storage and dynamic scaling technology, effectively reduces storage costs. At the same time, the strict access control and encryption techniques significantly minimize the risk of information leakage, achieving efficient and safe storage for off-chain blockchain data.
+
+### Ecosystem Fit
+
+Within the existing Polkadot ecosystem, there is a discernible gap for requisite application deployment service platforms suited for Web 2.5. This gap is precisely where WeTEE presents its competence - by enabling application developers to expedite the development and deployment of diverse Web 2.5 applications. This accelerates the extension of Polkadot's application realms across a plethora of industries, notably within the sectors of social media, entertainment and finance.
+
+Web 2.5 applications play a pivotal role in attracting a broader spectrum of Web 2 users towards the growing Polkadot ecosystem. With the expansion of these user bases, Polkadot is not only gaining traction in numerical terms but it also represents a movement towards a more balanced and decentralized internet model.
+
+In addition, these Web 2.5 applications are potential catalysts for introducing a multitude of new commercial models in the Polkadot ecosystem. This can have a dual effect of fostering Polkadot's growth, as well as collaborating with traditional industries for shared advancements. As such, WeTEE's role in aiding application development projects is a substantial step towards increasing Polkadot's industry footprint.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Team leader
+ - BaiL - Senior Full-stack Development Engineer
+- Team members
+ - Nomad - Senior Product Manager
+
+### Contact
+
+- **Contact Name:** BaiL
+- **Contact Email:** bai@asyou.me
+- **Website:** [WeTEE](https://www.wetee.app)
+
+### Legal Structure
+
+- **Registered Address:** Wickhams Cay Ⅱ, Road Town, Tortola, VG1110, British Virgin Lslands
+- **Registered Legal Entity:** WETEE LIMITED
+
+### Team's experience
+
+- BaiL
+ - 12-years full stack software development experience
+ - Solid knowledge and experience with various programming language i.e. Go,Dart,Javascript,Rust
+ - Blockchain & Substrate enthusiast
+
+- Nomad
+ - 3-years UI/UX design experience
+ - 8-years senior product management experience, leading multiple Linux and Cloud-based products
+ - United nations sustainable development goals certificate Product Manager (UCPM) / Lean Product Manager (UCLPM)
+
+### Team Code Repos
+
+- Blockchain node：https://github.com/wetee-dao/chain
+- Worker operator：https://github.com/wetee-dao/worker
+- Entry of libos： https://github.com/wetee-dao/libos-entry
+
+## Development Status :open_book:
+
+We have accomplished the implementation of organization accounts and decentralized governance features based on Substrate-supported smart contracts. These accounts and governance functions accommodate tasks such as the management of organizational assets and voting-based decision making. Consequently, this establishes a transparent and verifiable method of governance for organizations.
+
+At the current stage, we are focused on establishing the first version of the on-chain cloud deployment platform for the project. Through Docker and Kubernetes related technologies, this module can automatically deploy smart contracts and back-end services to the blockchain with one click and invoke the computing resources of decentralized servers.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 3.5 months
+- **Full-Time Equivalent (FTE):** 2 FTE
+- **Total Costs:** 21,000 USD
+
+### Milestone 1 — Build the On-Chain Module
+
+- **Estimated duration:** 1 month
+- **FTE:** 2
+- **Costs:** 6,000 USD
+
+| 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 and send test transactions, which will show how the new functionality works. |
+| **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. |
+| 01. | Substrate module: worker | This pallet provides modules for the registration and staking of miner nodes, as well as accepting proof-of-work data and detailed file hashes and addresses from miners, and also provides withdrawal functions for miners, as well as closure (which can only be executed if all services have already stopped/migrated), and also provides channels for users to complain about miner nodes.
1. Worker cluster register
2. Worker cluster mortgage
3. Worker cluster upload proof of work data
4. Worker cluster withdrawal
5. Worker cluster stop
6. Worker cluster report |
+| 02. | Substrate module: app | This pallet provides users with the function of deploying and updating applications, as well as an interface for topping up applications. Users can prepay for the operation of the application, and miners can only unlock the fees paid by users after uploading proof of work.
1. TEE app create
2. TEE app update
3. TEE app set settings
4. TEE app recharge
5. TEE app stop |
+| 03. | Substrate module: task |This pallet provides users with the function of deploying and updating periodic/temporary tasks, where users can set the execution time and cycle of tasks. It also provides an interface for users to recharge their applications, allowing them to prepay for the operation of the application. Miners can only obtain revenue after uploading proof-of-work for single-task work.
1. TEE task create
2. TEE task update
3. TEE task set execute settings
4. TEE task recharge
5. TEE task stop |
+
+### Milestone 2 — Build the Worker Module
+
+- **Estimated duration:** 1 month
+- **FTE:** 2
+- **Costs:** 6,000 USD
+
+| 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 and send test transactions, which will show how the new functionality works. |
+| **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. |
+| 01. | TEE Image build guide | We will provide documentation to help programmers understand and execute compiling existing web2 programs into deployable mirrors on Wetee. Currently we provide documentation for compiling via Ego and Gramine. |
+| 02. | App Example | We will provide example programs to help programmers understand and execute compiling existing web2 programs into deployable mirrors on Wetee. Currently we provide Examples in Golang, Python, C, C++, and Rust. |
+| 03. | Worker K8S Operator |The k8s worker acts as a trusted controller in the wetee network. It securely stores deployment states, including manifests and defined secrets. Based on the manifests, the Worker uses remote attestation to authenticate the trusted execution environments of applications.
1. K8S Operator run in SGX
2. Listen to Wetee Node State
3. Worker cluster register
4. Worker cluster mortgage
5. Worker cluster withdrawal
6. Worker cluster stop |
+| 04. | Worker App Deploy |The application controller of the miner node is responsible for pulling settings from the chain and synchronizing them into the k8s/k3s cluster to complete application deployment/update.
1. TEE app create
2. TEE app update
3. TEE app set settings
4. TEE app recharge
5. TEE app stop |
+| 05. | Worker Task Deploy |Miner node task controller, responsible for executing assigned tasks, uploading execution logs, and synchronizing to the chain.
1. TEE task create
2. TEE task update
3. TEE task set execute settings
4. TEE task recharge
5. TEE task stop |
+
+### Milestone 3 — Worker Proof
+
+- **Estimated duration:** 1.5 month
+- **FTE:** 2
+- **Costs:** 9,000 USD
+
+| 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 and send test transactions, which will show how the new functionality works. |
+| **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**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) |
+| 01. | Worker remote attestation as proof of work | Remote attestation module, users can use it to check the confidential running status of the application in real time. The module will automatically generate worker proof and synchronize the hash of the remote proof file to the chain. Users or challengers can verify the verification status of the worker through the proof file.
1. Worker cluster remote attestation service
2. Worker upload remote attestation as proof of work |
+| 02. | Worker log as proof of work | Synchronize the log of application running through libos to worker, and synchronize the hash file to the chain to prove the correctness and stability of program execution, users can view the application log to determine the status of program execution.
1. Worker cluster upload app log of app as proof of work |
+| 03. | Worker monitoring as proof of work |Through libos, synchronize the resource usage status of the application to the worker, and synchronize the hash and resource usage data of the file to the chain. The chain will calculate the resources of the application and issue rewards for the worker.
1. Worker cluster upload app monitoring of app as proof of work |
+
+## Future Plans
+When you express interest in the future development of WeTEE, our team is deeply encouraged, as your support leads us to believe that our code and products will achieve meaningful and valuable results.
+
+This grant will allow us to focus on developing core features, laying a reliable business foundation for WeTEE. Upon reviewing the outcomes of our submitted grant, you will be able to easily verify WeTEE's core business using the documentation guidance and Docker examples provided by WeTEE.
+
+The R&D of WeTEE can be divided into three major stages, each of which contains several small R&D stages or iterative cycles:
+• Core R&D stage
+• User experience optimization stage
+• Ecosystem construction stage
+
+During the current core development stage, WeTEE will concentrate all research and development resources on WeTEE's own development, including on-chain workers, apps, tasks, as well as K3S/K8S operators relevant to physical servers, app deployment models, task deployment models, and worker attestation models.
+
+Once this part is completed, WeTEE will spend a small amount of time to reorganizing the code and conducting a retrospective on the completed work, after which the development will move into the next phase of core research and development.
+
+At this stage, the R&D content mainly includes the WeTEE test/main network, the WeTEE Dapp SDK, accessing the Polkadot mainnet using CoreTime, as well as the WeTEE monitoring system and the WeTEE Web user interface.
+
+After completing this stage of development, WeTEE will invite seed users to conduct usability testing and user acceptance testing, and operational work will be carried out in accordance with the requirements of WeTEE DAO. Following initial user feedback, targeted fixes and optimizations will be implemented to address any issues within WeTEE.
+
+The following will enter the third phase of core R&D, which is also the last core R&D phase in the current planning. In this phase, WeTEE will dynamically allocate R&D resources to the ‘blockchain-related’ or ‘hardware-related’ fields based on user and market feedback.
+• Blockchain-related:
+ ◦ Integrate https://github.com/paritytech/frontier and support wallet applications such as Metamask
+ ◦ Improve the multi-language version of the SDK to help users better integrate accounts and business between Web2 apps and Web3 DApps
+ ◦ Improve the decentralized collaboration system of WeTEE, allowing WeTEE users to view the status of application clusters and application deployment events at any time
+• Hardware-related:
+ ◦ Compatibility with AMD SEV confidential solution
+ ◦ Compatibility with Intel TDX confidential solution
+ ◦ Performance optimization of confidential computing, distributed storage, and network for server K3S/K8S.
+
+## Additional Information :heavy_plus_sign:
+
+The subproject DTIM of WeTEE won the first prize at the [Polkadot Hackathon 2023 Summer](https://dorahacks.io/hackathon/polkadot-hackathon-2023-summer/results).
diff --git a/applications/application-template-research.md b/applications/application-template-research.md
index 21591ec65c0..0b240e41ab1 100644
--- a/applications/application-template-research.md
+++ b/applications/application-template-research.md
@@ -5,7 +5,7 @@
> See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal.
- **Team Name:** Legal name of your team (e.g. JsonCorp)
-- **Payment Address:** In the case of fiat payment, please share your bank account privately with grants@web3.foundation via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here. Otherwise, provide the Polkadot ( for USDC & USDT) or Bitcoin payment address. Please also specify the currency. (e.g. 0x8920... (USDC))
+- **Payment Address:** In the case of fiat payment, please share your bank account privately with grants@web3.foundation via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here. Otherwise, provide the Polkadot (for USDC & USDT) payment address. Please also specify the currency. (e.g. 0x8920... (USDC))
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1, 2 or 3
> :exclamation: *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.*
@@ -121,7 +121,7 @@ Below we provide an **example roadmap**. In the descriptions, it should be clear
- **Total Estimated Duration:** Duration of the whole project (e.g. 2 months)
- **Full-Time Equivalent (FTE):** Average number of full-time employees working on the project throughout its duration (see [Wikipedia](https://en.wikipedia.org/wiki/Full-time_equivalent), e.g. 2 FTE)
-- **Total Costs:** Requested amount in USD for the whole project (e.g. 12,000 USD). Note that the acceptance criteria and additional benefits vary depending on the [level](../README.md#level_slider-levels) of funding requested. This and the costs for each milestone need to be provided in USD; if the grant is paid out in Bitcoin, the amount will be calculated according to the exchange rate at the time of payment.
+- **Total Costs:** Requested amount in USD for the whole project (e.g. 12,000 USD). Note that the acceptance criteria and additional benefits vary depending on the [level](../README.md#level_slider-levels) of funding requested.
### Milestone 1 Example — Literature Review and Data Collection
@@ -164,7 +164,7 @@ Please include here
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 (USDC/DAI) or Polkadot/Kusama (USDT) payment address. Please also specify the currency. (e.g. 0x8920... (DAI))
+- **Payment Address:** Polkadot/Kusama (USDT) payment address. Please also specify the currency. (e.g. 0x8920... (USDC))
## Additional Information :heavy_plus_sign:
diff --git a/applications/application-template.md b/applications/application-template.md
index 807793e767d..2b6fa3222db 100644
--- a/applications/application-template.md
+++ b/applications/application-template.md
@@ -1,11 +1,11 @@
# Name of your Project
-> 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 (except for the title)! Lines starting with a `>` (such as this one) should be removed. Please use markdown instead of HTML (e.g. `` instead of `![]()
`).
+> 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 (except for the title)! Lines starting with a `>` (such as this one) should be removed. Please use markdown instead of HTML (e.g., `` instead of `![]()
`).
>
> See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal.
- **Team Name:** Legal name of your team (e.g. JsonCorp)
-- **Payment Address:** In the case of fiat payment, please share your bank account privately with grants@web3.foundation via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here. Otherwise, provide the Polkadot (for USDC & USDT) or Bitcoin payment address. Please also specify the currency. (e.g. 0x8920... (USDC))
+- **Payment Address:** In the case of fiat payment, please share your bank account privately with grants@web3.foundation via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here. Otherwise, provide the Polkadot (for USDC & USDT) payment address. Please also specify the currency. (e.g. 0x8920... (USDC))
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1, 2 or 3
> :exclamation: *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.*
@@ -14,13 +14,13 @@
If this application is in response to an RFP, please indicate this on the first line of this section.
-If this is an application for a follow-up grant (the continuation of an earlier, successful W3F grant), please provide name and/or pull request of said grant on the first line of this section.
+If this is an application for a follow-up grant (the continuation of an earlier, successful W3F grant), please provide the name and/or pull request of said grant on the first line of this section.
### Overview
Please provide the following:
-- If the name of your project is not descriptive, a tag line (one sentence summary).
+- If the name of your project is not descriptive, a tagline (one sentence summary).
- A brief description of your project.
- An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.
- An indication of why your team is interested in creating this project.
@@ -35,7 +35,7 @@ We expect the teams to already have a solid idea about your project's expected f
- Documentation of core components, protocols, architecture, etc. to be deployed
- PoC/MVP or other relevant prior work or research on the topic
- What your project is *not* or will *not* provide or implement
- - This is a place for you to manage expectations and to clarify any limitations that might not be obvious
+ - This is a place for you to manage expectations and clarify any limitations that might not be obvious
Things that shouldn’t be part of the application (see also our [FAQ](../docs/faq.md)):
@@ -51,12 +51,16 @@ Help us locate your project in the Polkadot/Substrate/Kusama landscape and what
- Where and how does your project fit into the ecosystem?
- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
- What need(s) does your project meet?
+- How did you identify these needs? Please provide evidence in the form of (scientific) articles, forum discussions, case studies, or raw data.
- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
- - If so, how is your project different?
- - If not, are there similar projects in related ecosystems?
+ - If so, how is your project different? Please identify and assess any projects addressing the same need and explain how your project is distinct. Feel free to include applicable research data, statistics, or metrics.
+ - If not, please indicate why such a project might not have been possible, successful, or attempted.
+- Are there any projects similar to yours in related ecosystems?
## Team :busts_in_silhouette:
+> Please note that the data provided in this section is for administrative and informational purposes only. All beneficiaries of a grant must also be listed in the KYC/KYB process during the application phase. See our [FAQ](https://grants.web3.foundation/docs/faq#what-is-kyckyb-and-why-do-i-have-to-provide-this-data) for more info.
+
### Team members
- Name of team leader
@@ -111,13 +115,13 @@ This section should break the development roadmap down into milestones and deliv
Below we provide an **example roadmap**. In the descriptions, it should be clear how your project is related to Substrate, Kusama or Polkadot. We *recommend* that teams structure their roadmap as 1 milestone ≈ 1 month.
-> :exclamation: If any of your deliverables is based on somebody else's work, make sure you work and publish *under the terms of the license* of the respective project and that you **highlight this fact in your milestone documentation** and in the source code if applicable! **Projects that submit other people's work without proper attribution will be immediately terminated.**
+> :exclamation: If any of your deliverables are based on somebody else's work, make sure you work and publish *under the terms of the license* of the respective project and that you **highlight this fact in your milestone documentation** and in the source code if applicable! **Projects that submit other people's work without proper attribution will be immediately terminated.**
### Overview
- **Total Estimated Duration:** Duration of the whole project (e.g. 2 months)
- **Full-Time Equivalent (FTE):** Average number of full-time employees working on the project throughout its duration (see [Wikipedia](https://en.wikipedia.org/wiki/Full-time_equivalent), e.g. 2 FTE)
-- **Total Costs:** Requested amount in USD for the whole project (e.g. 12,000 USD). Note that the acceptance criteria and additional benefits vary depending on the [level](../README.md#level_slider-levels) of funding requested. This and the costs for each milestone need to be provided in USD; if the grant is paid out in Bitcoin, the amount will be calculated according to the exchange rate at the time of payment.
+- **Total Costs:** Requested amount in USD for the whole project (e.g. 12,000 USD). Note that the acceptance criteria and additional benefits vary depending on the [level](../README.md#level_slider-levels) of funding requested.
### Milestone 1 Example — Basic functionality
@@ -133,7 +137,7 @@ Below we provide an **example roadmap**. In the descriptions, it should be clear
| **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 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**/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.) |
+| 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: X | We will create a Substrate module that will... (Please list the functionality that will be implemented for the first milestone. You can refer to details provided in previous sections.) |
| 2. | Substrate module: Y | The Y Substrate module will... |
| 3. | Substrate module: Z | The Z Substrate module will... |
@@ -155,7 +159,8 @@ Below we provide an **example roadmap**. In the descriptions, it should be clear
Please include here
-- how you intend to use, enhance, promote and support your project in the short term, and
+- how you intend to finance the project's long-term maintenance and development,
+- how you intend to use, enhance, and promote your project in the short term, and
- the team's long-term plans and intentions in relation to it.
## Referral Program (optional) :moneybag:
@@ -163,7 +168,7 @@ Please include here
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 (USDC/DAI) or Polkadot/Kusama (USDT) payment address. Please also specify the currency. (e.g. 0x8920... (DAI))
+- **Payment Address:** Polkadot/Kusama (USDT/USDC) payment address. Please also specify the currency. (e.g. 0x8920... (USDT))
## Additional Information :heavy_plus_sign:
diff --git a/applications/binary_merkle_tree.md b/applications/binary_merkle_tree.md
index 5d4bc060533..83b6ae7942f 100644
--- a/applications/binary_merkle_tree.md
+++ b/applications/binary_merkle_tree.md
@@ -3,7 +3,7 @@
- **Team Name:** ALPHA LABS FZCO
- **Payment Address:** 0x503b14fCcbAD63A1d6054D07f8B4685dCf5db7c3 (USDT ERC20)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
-
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1179#issuecomment-1742345375)
## Project Overview :page_facing_up:
diff --git a/applications/centrifuge-twamm.md b/applications/centrifuge-twamm.md
index d5b66de39bc..59b963763b4 100644
--- a/applications/centrifuge-twamm.md
+++ b/applications/centrifuge-twamm.md
@@ -335,6 +335,8 @@ We would like to bring to your attention that we recently presented a similar, a
### Milestone 1 - TWAMM Pallet
+We anticipate the project's inception to be in the second quarter of 2024.
+
- **Estimated duration:** 7.5 weeks (286 hours)
- **FTE:** 1.5
- **Costs:** 75,000 USD
diff --git a/applications/community-health-check.md b/applications/community-health-check.md
index 8d1bfa7a66b..a9ce321cdea 100644
--- a/applications/community-health-check.md
+++ b/applications/community-health-check.md
@@ -105,7 +105,7 @@ Our current approach rests on off-chain data. Other community analytics dashboar
Looking at on-chain community analysis, Chainverse is similar in terms of methodology (network analysis). However, they are currently solely focusing on on-chain data and are adopting a knowledge graph methodology.
-There is a [RFP for website and on-chain data analysis ](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/analysis-website-and-data-platform.md). The RFP is about creating an "easy-to-use front-end with sharable customized dashboards" and thus broader than our proposal.
+There is a [RFP for website and on-chain data analysis ](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/analysis-website-and-data-platform.md). The RFP is about creating an "easy-to-use front-end with sharable customized dashboards" and thus broader than our proposal.
## Team :busts_in_silhouette:
diff --git a/applications/contracts-tool.md b/applications/contracts-tool.md
index 77d17339ada..4c49548afd4 100644
--- a/applications/contracts-tool.md
+++ b/applications/contracts-tool.md
@@ -135,13 +135,13 @@ Work has been started, smart bench has been updated with new libraries and is ab
### Overview
-- **Total Estimated Duration:** 3 months
-- **Full-Time Equivalent (FTE):** 0.5
+- **Total Estimated Duration:** 7 months
+- **Full-Time Equivalent (FTE):** 0.3
- **Total Costs:** 15000 EUR
### Milestone 1 Smart-bench updated — Basic functionality
-- **Estimated duration:** 5 weeks
+- **Estimated duration:** 10 weeks
- **FTE:** 0.5
- **Costs:** 6500 EUR
@@ -158,8 +158,8 @@ Work has been started, smart bench has been updated with new libraries and is ab
### Milestone Smart-bench in CI/CD flow — Additional features
-- **Estimated Duration:** 7 weeks
-- **FTE:** 0,5
+- **Estimated Duration:** 23 weeks
+- **FTE:** 0,25
- **Costs:** 8500 EUR
| Number | Deliverable | Specification |
@@ -172,6 +172,7 @@ Work has been started, smart bench has been updated with new libraries and is ab
| 1. | Github Actions benchmark jobs | Create workflow and implement a job to utilize Dockerized benchmarking for generating results and uploading them to repository. |
| 2. | Results processing tools | Implementation of tooling to translate smart-bench output format to format of InfluxDB. |
| 3. | Github Actions workflow | Create complete workflow running parallel jobs based on matrix strategy for all missing measurements. |
+| 4. | Updated smart-bench | We will update the tool to use new subxt crate |
...
diff --git a/applications/data_platform_with_deep_indexed_data_and_staking_reports.md b/applications/data_platform_with_deep_indexed_data_and_staking_reports.md
index 1096c774403..7333532ac91 100644
--- a/applications/data_platform_with_deep_indexed_data_and_staking_reports.md
+++ b/applications/data_platform_with_deep_indexed_data_and_staking_reports.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-Current proposal is the solution from [P2P.org](http://P2P.org) for the problem described in [Analytics Website/Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/analysis-website-and-data-platform.md) RFP.
+Current proposal is the solution from [P2P.org](http://P2P.org) for the problem described in [Analytics Website/Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/analysis-website-and-data-platform.md) RFP.
### Overview and Ecosystem Fit
diff --git a/applications/decentral_ml.md b/applications/decentral_ml.md
new file mode 100644
index 00000000000..eef588db329
--- /dev/null
+++ b/applications/decentral_ml.md
@@ -0,0 +1,198 @@
+# Decentral ML
+- **Team Name:** Seed Intelligence Limited
+- **Payment Address:** Fiat 03.01.2024, 04:04
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+This is a new funding application and is not in response to an RFP, nor a follow-up grant.
+
+### Overview
+
+One-liner: A Polkadot protocol for decentralised federated machine learning and collective governance.
+
+Project Description:
+DecentralML introduces decentralised federated machine learning (DFML), governed by collective consensus to the Polkadot ecosystem. Our goal is to provide a robust framework for AI model developers, organisations, and applications, enabling decentralised ownership of models while ensuring privacy and scalability. With node or on-device training protecting privacy, the ability to pool training data, collaborative AI training, and "collective" governance controls, DecentralML may transform the field of machine learning for state-of-the-art AI models (think LLMs and more) with transparent governance.
+
+Integration with Substrate / Polkadot / Kusama:
+DecentralML is built upon the Substrate framework, and leverages the Tensorflow's Federated Machine Learning library enabling seamless integration into the Polkadot ecosystem. By leveraging Substrate's flexible and modular pallet architecture, we can shortcut a lot of the overhead needed to create a chain that has a dynamic collective consensus governance approach for things like AI model weights and other safety measures along with higher level controls for licensing of the entire models, jurisdiction training rules and other multi-territorial controls.
+
+The project aims to be as open and flexible as possible to integrate with other project with an innovative "bring your own" (BYO) token staking economy (faciliated by Pallets such as Balances, Grandpa, Ink! etc).
+
+We hope for active engagement from the wider Polkadot developer network once the project is complete or even during its development. We strongly believe that this project holds the potential to transform and advance the entire AI industry.
+
+Team Motivation:
+Our team is driven by the urgent need to challenge the dominance of centralised corporates like Facebook, OpenAI, Microsoft, etc, in the field of AI model development. These companies have built powerful models that require significant computing power and data, are not environmentally efficient, limit access to AI capabilities and, potentially, create a safety threat to humankind. We believe that these models could not only be statistically improved if they were decentralised, but also may improve power usage efficiency and reduce safety concerns by being transparently controlled by humankind on-chain, rather than a select number of corporations.
+
+Our second motivation as Livetree involves a solution for our AI tasks, such as video processing, speech-to-text, facial recognition, scene detection, and content recommendations. We currently solve these challenges using centralised model solutions and would like to transition to a decentralised model. For further demonstrations or information on Livetree, feel free to download the free Livetree app and try speech-to-text or contact us. We will gladly provide instructions on how you can try the AI models within our app and provide the raw AI JSON processing results for object detection, landmark recognition, speech-to-text, and other AI processor outputs.
+
+We are passionate about decentralisation and see the limitations of centralisation in terms of quality of the models, data ownership, privacy, and safety control. This has fueled our motivation to decentralise these models and create a decentralised federated machine learning module.
+
+
+### Project Details
+
+We have made significant progress in integrating TensorFlow's Federated Machine Learning (FML) library within a decentralized Polkadot Substrate environment. This innovative approach combines the power of decentralized machine learning with the robustness of Polkadot's governance and consensus mechanism. The key objectives of our project can be summarised as follows:
+
+1. Personal data privacy: Our approach ensures that the model is trained on the local node or device, with only the model inferences synchronised through consensus. This preserves privacy as private data never leaves the device/node, protecting user data and maintaining confidentiality.
+
+2. Improved model quality: By enabling a diverse set of nodes to contribute to the training process, our decentralized approach allows for a wider range of data inputs. This results in better model insights and intelligence that may surpass current centralised models, leading to more accurate, comprehensive and widely available models.
+
+3. Safety and governance: The governance of consensus built within the Polkadot Substrate framework enables open collective voting on crucial aspects such as model weights, jurisdictional usage, costs, and model selection. This provides a transparent and secure environment for the future AI collective society to make informed decisions and ensures the safety and reliability of the models.
+
+
+
+#### Architecture Overview
+
+##### Logical Components
+
+
+
+
+**Data Management**: Blockchain-based encrypted data storage system that ensures immutable data storage and securely provides data access via protocols and apis.
+
+**Federated Learning Consensus**:Implements federated learning algorithms like Federated Averaging or Secure Aggregation for collaborative model training across distributed nodes.
+
+**Collective Economy**: Implements decentralized governance using a collective model, to enable decision-making amongst participants to vote on model updates, protocol changes, network parameters, reputation systems, model licensing, nodes lists and incentive mechanisms to encourage active node participation, discourage malicious behavior, and reward contributors.
+
+**Model Deployment**: Model serving frameworks (e.g., TensorFlow Serving, PyTorch Lightning) for deploying trained models for production usage, including monitoring tools and frameworks for tracking model performance, latency, and resource utilisation.
+
+**Client Interface**: This component acts as a facade providing a universal interface to the deployed models and other aspects of the system for a range of DevTools, SDKs, and user interfaces.
+
+
+##### Implementation
+
+**Data Management**: Current implementation uses IPFS, however, as part of the grant we plan to make this modular so other dentralised and, potentially, distributed storage systems (such as HDFS) might be dynamically utilised.
+
+**Federated Learning Consensus**: Implements the federated learning process which involves multiple stages:
+1. Client Selection: Selecting a subset of clients or nodes themselves to participate in each round of model training.
+2. Model Distribution: Distributing the initial model or updated model parameters to the selected clients.
+3. Local Model Training: Clients perform model training on their local data using the received model parameters.
+4. Model Aggregation: Aggregating the updated model parameters from the clients to generate a node model update.
+5. Model Update Application: Applying the node model update via consensus to the global model.
+
+Nodes are rewarded for successfully improving the model. This happens at "Model Update Application" stage whereabouts the global model is segregated into training, testing and results data partitions. The application of the node gradient update should result in the testing partition. If the results when compared to the testing partition prove successful then the node is awarded tokens in order to pay for the required resources—processors, memory, storage, and network bandwidth used to perform the federated learning. As part of this grant we will introduce token staking so any Polkadot compatible token can be used enabling the framework to support external token ecomonies.
+
+**Collective Economy**: By submitting and voting on proposals—referenda—the DecentralML community can determine what models should be trained, the thresholds for node rewards per model, clients eligible for training, and other ownership and training specifics. These include but are not limited to jurisdicational licensing fees for model deployment and other safety measures such as weights or algorithms related to the model.
+
+**Model Deployment and Client Interface**: The ability to interact with the models and chain will be limited to a simple Javascript/Typescript set of interfaces primarily for model submission, and parameterisation through governance.
+
+
+#### Technology stack
+
+- Python/TensorFlow
+- Rust/Substrate
+- IPFS
+
+
+
+### Ecosystem Fit
+
+The team has engaged with core members of the Polkadot team who have shown keen interest in the convergence of federated ML and decentralization. Through active discussions with key technical leads, we have identified immense potential to revolutionise the field of artificial intelligence using the Substrate framework and the Polkadot's developer network. Our goal is to democratise and decentralise AI models development by introducing decentralised federated machine learning, surpassing the capabilities of centralised entities. With privacy protection at the core, industries ranging from healthcare to creator and social networks can benefit from our solution.
+
+To our knowledge, there are currently two AI-related projects in the Substrate/Polkadot/Kusama ecosystem: DeepBrainChain and BitTensor. DeepBrainChain focuses on decentralised GPU server compute, while BitTensor offers a marketplace for ranked models. DecentralML brings decentralised federated machine learning to the ecosystem, making it an exciting addition to the Polkadot ecosystem.
+
+## Team :busts_in_silhouette:
+
+
+### Team members
+- Name of team leader:
+ - Ashley Turing
+- Names of team members:
+ - Dr Jamie Ward
+ - Isak Grimsson
+ - Mathias Ciliberto
+
+ We have also made contact with wider related field researchers:
+[Dr. Philip Treleaven](http://www0.cs.ucl.ac.uk/staff/P.Treleaven/) | [Dr Jonathan M M Hall](https://drjonathanmmhallfrsa.wordpress.com/) | [Jesse C. Cresswell](https://scholar.google.ca/citations?user=7CwOlvoAAAAJ&hl=en)
+
+
+### Contact
+
+- **Contact Name:** Ashley Turing
+- **Contact Email:** at@livetree.com
+- **Livetree App:**
+
+
+### Legal Structure
+
+- **Registered Address:** Freda St, London, UK
+- **Registered Legal Entity:** Seed Intelligence Limited
+
+### Team's experience
+The team consists of computer science academics and software engineers, including Dr. Jamie Ward, a senior lecturer in machine learning at Goldsmith's University, Isak Grimson, a computer science graduate specialising in machine learning research, and Ashley Turing, an experienced computer software engineer with expertise in blockchain technologies.
+
+
+### Team Code Repos
+
+-
+
+-
+
+
+
+### Team LinkedIn Profiles (if available)
+
+- Ashley Turing
+
+- Jaime Ward
+
+
+- Isak Grimsson
+
+
+## Development Status :open_book:
+
+The current whitepapers for BitSensor and DeepBrainChain
+- [BitSensor](https://drive.google.com/file/d/1VnsobL6lIAAqcA1_Tbm8AYIQscfJV4KU/view)
+- [DeepBrainChain](https://www.deepbrainchain.org/assets/pdf/DeepBrainChainWhitepaper_en.pdf)
+
+
+Here are key publications in the field of decentralised federated machine learning:
+
+- [Federated Learning: The Pioneering Distributed Machine Learning and Privacy-Preserving Data Technology](https://ieeexplore.ieee.org/abstract/document/9755189)
+- [A novel decentralized federated learning approach to train on globally distributed, poor quality, and protected private medical data](https://www.nature.com/articles/s41598-022-12833-x)
+- [Decentralized federated learning through proxy model sharing](https://www.nature.com/articles/s41467-023-38569-4)
+
+
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 2 months
+- **Full-Time Equivalent (FTE):** 2.5
+- **Total Costs:** 30,000 USD
+
+### Milestone 1 — Federated Learning Consensus & Data Management Implementation
+
+- **Estimated duration:** 4 weeks
+- **FTE:** 2.5
+- **Costs:** 15,000 USD
+
+
+| Number | Deliverable | Specification |
+| ------: | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **0a.** | License | APACHE 2 |
+| **0b.** | Documentation | We will provide both a **Gitbook with basic tutorial** and **inline documentation** of the code that explains how a user can (for example) upload and train a model, this will show how the federated machine learning functionality works. |
+| **0c.** | Testing and Testing Guide | Unit test will comprehensively cover core functions ensuring both functionality and robustness. In the Gitbook, 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. | Data Management Implementation | DecentralML, aims to establish a system of on-chain incentives and charges for the four key parties involved in the model's training and utilization. These parties are defined as:
i) Model Engineers: These are the data scientists, mathematicians, and computer scientists who develop and refine the models.
ii) Data Annotators: These users enrich the model by providing labels and annotations.
iii) Data Contributors: These users enhance the model by adding gradients.
iv) Clients: These are the licensors of the model who may wish to use the model for commercial, contribution or educational purposes.
Our initial step in this process involves storing the "Master" model in a decentralized storage system. This DecentralML "PUT" method will be parameterized, allowing for the selection of different storage types (e.g., 1=IPFS, 2=Another storage type). We will abstract the data management to support pluggable data storage implementations and will implement IPFS initially. Note: In the future, we would like to support different decentralised storage types to test for update speed, retrieval and caching (see [Decentralised data options for polkadot](https://wiki.polkadot.network/docs/build-storage))
The "Model Creator" initiates the upload by calling DecentralML methods using the Substrate Python Client library. Initially, uploading the "Master Model" and defining the "Training" parameters. These parameters include but are not limited to the following:
1. The staked pool payable amount is sent by the "Model Creator" and stored on-chain as either DOT (or relevant compatible coin). These assets will ultimately be used to incentivize Data Contributors, Model Engineers, and Data Annotators.
2. The percentage of the pool allocated to the Data Contributors, Model Engineers, and Data Annotators.
3. The charges for Model Engineers to download the model.
4. The charges for Licensors of the model to download it.
These DecentralML parameters will be set using the Python client library by the "Model Creator". The method will return a global unique identifier for the model.|
+| 2. | Federated Learning Consensus | We will write the core of rewarding "Data Contributors". Our focus will be on supporting Google's [TensorFlow's Federated Learning](https://www.tensorflow.org/federated) implementation, given its widespread client support and the substantial commercial funding it has received for development. However, we acknowledge the limitations of this approach, particularly in relation to the [ProxyModel approach](https://github.com/layer6ai-labs/ProxyFL), and we may consider modifying TensorFlow's core FL libraries in future releases to incorporate the ProxyModel approach. In terms of specific deliverables we plan on developing two DecentralML methods:
1. defineDataContributors([clientId], [walletaddress]): This method, called by the Model Creator (MC), identifies the "Data Contributors" who are eligible to train the model. The clientId is generated by the TensorFlow FL library. It is the MC's responsibility to manage and develop the relevant Client specific applications using TensorFL client libraries. This method is expected to be called before the "Client Selection" step outlined in the "Implementation > Federated Learning Consensus" section of this application. In this context, DecentralML serves as an auditing and reward mechanism for the Data Contributors.
2. rewardDataContributors([clientIdArray],[0-1]): This method, also called by the MC, rewards the Client for their data contribution. We anticipate this function being called after step 4, Model Aggregation, once the MC has determined a score (defined as the second parameter, ranging from 0-1). This score represents a percentage of the remaining "Data Contributors Pool" defined during the initial upload of the "Master Model". The method then allocates the assets to the Data Contributors' wallet. The advantage of this approach is that it requires minimal modifications to the TensorFlow FL library. Instead, we focus on rewarding and providing transparency for each set of gradients passed by the client, thereby incentivizing the client to contribute data to the model.
We will also add additional administrative methods as needed, such as the ability to upload the associated Client gradients and query the allocation on-chain.
+
+
+### Milestone 2 — Collective Economy and Client Interface
+
+- **Estimated duration:** 4 weeks
+- **FTE:** 2.5
+- **Costs:** 15,000 USD
+
+
+| Number | Deliverable | Specification |
+| ------: | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **0a.** | License | APACHE 2 |
+| **0b.** | Documentation | We will provide both a **Gitbook with basic tutorial** and **inline documentation** of the code that explains how a user can (for example) work with governance and stake against a model and how the client interface works. |
+| **0c.** | Testing and End-to-end (e2e) Testing Guide | Comprehensive unit tests to ensure core functionality and robustness of code. Instructions on how to run the tests will be included. End-to-end federated learning test using the MNIST dataset for classification |
+| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | | |
+| **0e.** | Robust Incentivisation Scheme | In response to the feedback received, we will implement a random role assignment mechanism as part of our example game logic. We also see the value in having some flexibility in role assignments, similar to the VBFL paper. This will be configurable using the strategy pattern, thereby addressing the "game theory" concerns. As in the VBFL paper, at every communication round, each device will be randomly appointed as one of the three roles defined as follows: (1) "Data Contributors" can occasionally take on the role of "machine learning worker," as described in the VBFL paper. (2) The role of "model validator" will be an extension of our existing validation processes. This role will employ advanced validation techniques like k-fold and stratified sampling to ensure the integrity and accuracy of model training. This role can be dynamically assigned as with the "machine leanring worker" and "blockchain miner" roles, adding an extra layer of robustness. (3) The "blockchain miner" role will be responsible for incorporating validated models into the blockchain. | | | |
+| 1. | Collective Economy | We plan to establish governance mechanisms related to the selection and training of models, specifically for Data Annotators and Model Engineers.
For Model Engineers, we will implement the following logical methods:
1. listMasterModels: This method returns a report listing the modelGUID, modelName, usageType, usageTypeCost, and costTokenAccept.
2. getMasterModels(licenseUsage, quantityOfPaymentCoins): This method takes the type of usage and the payable amount for that usage, returning the master model. It operates on an element of trust, with users expected to pay the appropriate amount based on the associated licensing (MIT, Apache, etc. defined on-chain for the model). While we don't anticipate this being a problem for this grant, future releases may include more sophisticated whitelists or permissions.
3. listModelEngineers(modelGUID): This method returns a list of Model Engineer (ME) wallet addresses approved to call the collectiveApprovesModel method.
4. modelEngineerUpdate(modelGUID, model, senderWalletAddress): Anyone can send their version of the model, which will be stored on-chain for review and approval. We may add more permissions to this method but the idea is to keep it as open as possible.
5. listModelEngineerUpdates(modelGUID): This method returns a report listing the senderWalletAddress, model version, block number, and updateID.
6. collectiveApprovesModel(updateID, collective member or MC sender address, reward percentage:0-1): This method approves the model to replace the "Master" model and awards the Model Engineer a percentage (defined in the parameter 0-1) from the Model Engineer pool.
7. addCollectiveMember(modelGUID, walletAddress): This method adds collective members to the approval list so updates to the model by MEs can be approved. Future expansions may support issues like jurisdiction, licensing, usage, as well as parameter settings for algorithm selection and more.
For Data Annotators, we will implement similar logical methods:
1. `uploadDataForAnnotation(image, text, sound, testQuestionnaire:questionText, answerType, questionId, answerPoints:numberPointsRewarded, batchParameters)`: This method allows collective members to provide data that requires annotation. The solution design records the answer types as columns and the questions as rows, enabling a wide variety of annotation questions to be modelled depending on the model requirement.
2. `getDataAnnotationQuestionnaire(modelGUID)`: This method returns a list of required data annotations and associated questionnaire information with data types as columns, offering flexibility to build a wide variety of dApps that could harness and offer various rewards to DAs.
3. `submitDataAnnotationForReward(modelGUID, questionId, answer)`: This method implements a simple validation test for the submitted annotated data, with the potential for more sophisticated game theory algorithms to validate DA submissions in the future.
4. `reportDataAnnotationAwards(modelGUID)`: This method returns a report of pending and allocated rewards.
+| 2. | Client Interface | We will focus on utilising Substrate api-client libraries, particularly the Python library. We won't be developing a user interface for Data Annotators or any other specific targetted party. Instead, our attention will be on integrating a Python library, which could potentially be used with applications like Jupyter Notebooks and other machine learning tools in the future. It's important to note that we anticipate commerical "Clients" will use the 'getMasterModel' method, as outlined in the Collective Economy section above. |
\ No newline at end of file
diff --git a/applications/delightfuldot.md b/applications/delightfuldot.md
new file mode 100644
index 00000000000..8e6b40fea39
--- /dev/null
+++ b/applications/delightfuldot.md
@@ -0,0 +1,184 @@
+# DelightfulDOT
+
+- **Team Name:** Coong Crafts (formerly Coong Team)
+- **Payment Address:** 15GJvMYDXXU5Xr795kP5VdsfccWS7Hcug5smWjN6gEELvWaT (AssetHub - USDT)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### 1. Overview
+Dapps have always been a very important part of any blockchain ecosystem, it is where users can connect and interact with blockchain nodes. Given the complex nature of interacting with Substrate-based blockchains, in order for developers to focus on the business logic, a middle layer between dapps and blockchain nodes to facilitate the connections & interactions is always an essential part of the ecosystem and this is where `@polkadot/api` comes in.
+
+`@polkadot/api` has done a great job in helping applications connect to networks in an easy and effortless way by abstracting away all the complexities of connecting with a Substrate-based blockchain and scale-codec serialization process under the hood. But through development experience, benchmarking and profiling, we found out that `@polkadot/api` has a relatively high memory consumption, which might not be problematic for dapps that only connect to one or a few networks, but for dapps that need to connect to dozens or even hundreds of networks at the same time, it’s a problem which might create a great impact on the overall user experience (e.g: a wallet app or portfolio app needs to connect to a large number of networks to fetch users’ balances & assets or to listen to on-chain events).
+
+- If we enable all 100+ Substrate networks on SubWallet, it could increase the memory consumption to over a GB of RAM.
+
+
+- Talisman is having their own solution for connecting to networks and fetching balances effectively without relying on `@polkadot/api` ([@talismn/balances](https://github.com/TalismanSociety/talisman/tree/dev/packages/balances)**,** [@talismn/api](https://github.com/TalismanSociety/api)).
+- We ran [a NodeJS script](https://github.com/sinzii/delightfuldot-poc/blob/main/src/benchmarks/benchmark_connect_multiple_endpoints.ts) that connects to 100 substrate-based network endpoints to fetch balances for an account using `@polkadot/api`, and the average memory consumption is over 800MB. More details about the benchmark results could be found [here](https://github.com/sinzii/delightfuldot-poc/tree/main#memory-consumption-benchmark-result).
+
+As we’re heading toward a multi-chain future, there will absolutely be more parachains, parathreads or solochains built on Substrate to come, and users might have assets spreading over dozens or hundreds of networks. With that, we do see the need of connecting to a large number of networks at the same time effectively and efficiently, Coong Crafts propose to build `delightfuldot`, an alternative solution to `@polkadot/api` to address this issue in contributing to the whole effort of paving the way to a multi-chain future of the Polkadot & Kusama ecosystem.
+
+### 2. Project Details
+
+**2.1. Why does `@polkadot/api` has a high memory consumption?**
+
+We ran memory profiling for a [NodeJS script](https://github.com/sinzii/delightfuldot-poc#profiling) to connect to Polkadot network to see how much memory `@polkadot/api` consume during the bootstrapping process (initialization). Below are captures of the results:
+- Result of `Allocation sampling` profiling via Google Dev Tools
+
+
+- Result of `Allocation instrumentation on timeline` profiling via Google Dev Tools
+
+
+From the results, we can see that the memory consumption from `Metadata` and its type system is relatively high. As we looked into the source code itself, we found out that `@polkadot/api` has its own types and structure for every piece in the metadata, during the decoding process it will create types for all of the pieces in the metadata hierarchy/structure which result in the lot of `Type` objects and a big `Metadata` object ([`PortableRegistry` is a part of the Metadata](https://github.com/polkadot-js/api/blob/319535a1e938e89522ff18ef2d1cef66a5af597c/packages/types/src/interfaces/metadata/v14.ts#L43-L47))
+
+We tried to build a [small proof of concept alternative solution](https://github.com/sinzii/delightfuldot-poc/tree/main/src/poc) using [`scale-ts`](https://github.com/paritytech/scale-ts) (now `subShape`) for scale-codec encoding/decoding to do the same functionality and the memory consumption has improved noticeably.
+
+
+Going further, instead of connecting to 1 network, this time we tried to connect to 20, 50, and 100 network endpoints to fetch balances for an account using `@polkadot/api` and our PoC solution for comparison, and as we can see from the [benchmark result](https://github.com/sinzii/delightfuldot-poc#memory-consumption-benchmark-result), the memory consumption of our PoC solution is significantly smaller. More details about the benchmarking could be found in [our PoC repository](https://github.com/sinzii/delightfuldot-poc#benchmark-memory-consumption-when-connecting-to-multiple-network-endpoints).
+
+**2.2. Design Goals & Approach**
+
+_**2.2.a. API style similar to `@polkadot/api`**_
+
+`@polkadot/api` is currently using an [easy-to-use and intuitive API style](https://polkadot.js.org/docs/api/start/basics#metadata) (e.g: `api.query.system.account(address)` to query account balance, or `api.consts.[pallet_name].[constant_name]` to access constants of a pallet ...).
+
+So we decided to use the same API style so that users don’t have to learn new syntax when switching to using `delightfuldot` and making the migration progress easier.
+
+_**2.2.b. Less overhead evaluation**_
+
+During the bootstrapping process, `@polkadot/api` will try to register all possible type definitions ([ref1](https://github.com/polkadot-js/api/blob/319535a1e938e89522ff18ef2d1cef66a5af597c/packages/types/src/create/registry.ts#L193), [ref2](https://github.com/polkadot-js/api/blob/319535a1e938e89522ff18ef2d1cef66a5af597c/packages/types/src/create/registry.ts#L571)) and expose all available methods/props after decoding the metadata retrieved from a network ([ref](https://github.com/polkadot-js/api/blob/master/packages/api/src/base/Decorate.ts#L253)). This would help make the API execution faster but at the same time make the bootstrapping process longer and increase the overall memory consumption. Secondly, most of the dapps only use a few APIs and types (e.g: fetching balances, transfer balances or assets ...), so the registration of all of APIs and types would be unnecessary in most cases.
+
+`delightfuldot`'s approach is to perform API evaluation and execution on the fly, which is at the time an API is called, `delightfuldot` will check if the API is existed or not, register all necessary types (and cache those types if possible for later usage), execute the API and then handle the response.
+
+For example, upon calling `api.query.system.account('5xxxxx...')` to fetching balances for an account, `delightfuldot` will do the following steps:
+ - Check if the pallet named `System` is existed in the metadata, else throw an error.
+ - Check if the storage entry named `Account` is existed in the pallet `System` in the metadata, else throw an error.
+ - Gather all the necessary information to perform a storage query through an RPC `state_getStorage` like input types, output type, calculate storage entry hash …
+ - Execute RPC `state_getStorage` with the calculated storage entry hash
+ - Decode the response with the output type and return the decoded data.
+
+Unlike `@polkadot/api` where the first 2 steps are already done in the bootstrapping process. We believe that our approach would help speed up the bootstrapping process and reduce the overhead memory consumption. We archived this by using a [proxy technique](https://github.com/sinzii/delightfuldot-poc/blob/14eab8195c02fb6c48300812572437edd11ca707/src/poc/delightfuldot.ts#L82-L92), you could find more in detail about it in the PoC repository.
+
+_**2.2.c. Caching**_
+
+Metadata has always been an important part of any Substrate-based blockchain, it’s where we can find all information about on-chain functionalities (pallets, storage, extrinsics, constants, …), but it takes time to encode the metadata retrieved from networks and take space in the memory to store all of the information after decoding the metadata.
+
+Since Metadata is only updated through runtime upgrades, so `delightfuldot` will cache the decoded metadata information in the device’s storage (localStorage, IndexedDB, …) and only check to update it on runtime upgrade. This would also help speed up the bootstrapping process and reduce memory consumption since the metadata is now stored on the device’s storage.
+
+One drawback of this approach is that access speed to storage would be a bit slower than to memory, but given the benefits of the approach, we believe the tradeoffs are acceptable.
+
+**2.3. Vision**
+
+We set a vision for `delightfuldot` to become an essential part of Polkadot & Kusama ecosystem, so dapps can leverage its utilities to connect to and interact with hundreds of networks quickly and smoothly without having to think about memory consumption.
+
+This proposal is asking for a grant to support the first development phase of `delightfuldot` for the foundational modules with core functionalities. More details are in the upcoming section.
+
+**2.4. Foundational modules with core functionalities**
+
+This step, we aim to lay out all the necessary foundational pieces of the library and put all of them together to form the core functionalities, including:
+
+- New type system built on top of `scale-ts` (now `subShape`) with less memory consumption while at the same time can easily switch to use `@polkadot/api`'s type system for easy migration from existing dapps.
+- A metadata parser with abilities to decode & encode Metadata using scale-codec. In the scope of this grant, we plan to support the latest version of metadata which is v14.
+- Ability to execute RPCs to a Substrate-based node
+ - Each blockchain has its own custom list of supported RPCs, in the scope of this grant we plan to implement the supported RPCs of [Polkadot](https://polkadot.js.org/docs/polkadot/rpc) & [Kusama](https://polkadot.js.org/docs/kusama/rpc) networks.
+ - Support registering custom RPCs, so developers can easily add custom RPCs for their custom substrate node.
+- Ability to execute Runtime APIs
+ - Similar to RPCs, each substrate-based blockchain has its own list of supported Runtime APIs, so in the scope of this grant, we plan to implement the supported Runtime APIs of [Polkadot](https://polkadot.js.org/docs/polkadot/runtime) and [Kusama](https://polkadot.js.org/docs/kusama/runtime) networks.
+ - Support registering custom Runtime APIs
+- With the format of Metadata V14, on-chain functionalities are exposed through pallet’s definitions including pallet’s constants, storage entries, extrinsic calls, events & errors. We plan to support abilities to:
+ - Inspect pallet’s constants (similar to `@polkadot/api` APIs to inspect [constants](https://polkadot.js.org/docs/polkadot/constants))
+ - Inspect pallet’s events & errors (similar to `@polkadot/api` APIs to inspect [events](https://polkadot.js.org/docs/polkadot/events) & [errors](https://polkadot.js.org/docs/polkadot/errors))
+ - Execute pallet’s storage queries (similar to `@polkadot/api` APIs to execute [storage queries](https://polkadot.js.org/docs/polkadot/storage))
+ - Sign and submit extrinsics (similar to `@polkadot/api` APIs to [sign & submit extrinsics](https://polkadot.js.org/docs/polkadot/extrinsics))
+
+The work will be focused on building APIs to facilitate interactions with Substrate-based blockchain nodes, therefore we'll leverage existing solutions for creating, managing & signing keys in `@polkadot/keyring` package as well as other cryptography & utility functions in `@polkadot/util-crypto`, `@polkadot/util`.
+
+**2.5. Tech Stacks**
+- TypeScript
+- scale-ts (now subShape), rxjs
+- Helpful packages from `@polkadot/api`, `@polkadot/common`
+
+### Ecosystem Fit
+`delightfuldot` fits perfectly in the Polkadot & Kusama ecosystems as it provides a solution to a critical issue faced by dApps that need to connect to and interact with hundreds of networks efficiently & effectively. Any dApps (e.g wallet apps, portfolio apps, ...) that need to connect to a large number of networks can benefit from `delightfuldot`'s utilities.
+
+We as the maintainer of [Coong Wallet](https://grants.web3.foundation/applications/coong_wallet) see that `delightfuldot` is a stepping stone to the next development phase of Coong Wallet with more & more useful features in which Coong Wallet would need to connect to a large number of Substrate-based networks to fetching & syncing information.
+
+Aside from `@polkadot/api`, [`capi`](https://github.com/paritytech/capi) is another project to help craft interactions with Substrate-based blockchain, but at the time of writing this proposal, it’s going through a big restructuring, we’re not sure what would it look like until its shape be more concrete. Overall we don’t see any noticeable projects that are trying to solve the same problems as us.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Thang X. Vu (Team Leader)
+- Tung Vu
+
+### Contact
+
+- **Contact Name:** Thang X. Vu
+- **Contact Email:** thang@coongcrafts.io
+
+### Legal Structure
+
+N/A yet
+
+### Team's experience
+
+Coong Crafts is a small team set out with a mission to bring Web3 closer to the world. We previously completed a grant to build [Coong Wallet](https://grants.web3.foundation/applications/coong_wallet) ([PR](https://github.com/w3f/Grants-Program/pull/1387)), a website-based wallet solution to address the inconsistent wallet experience on mobile & desktop and bring a new approach to onboard new users to Polkadot & Kusama ecosystem.
+
+### Team Code Repos
+
+Project repositories will be hosted at https://github.com/CoongCrafts
+
+Team members
+- Thang X. Vu - https://github.com/sinzii
+- Tung Vu - https://github.com/1cedrus
+
+## Development Status :open_book:
+
+- We have been in research the `@polkadot/api` project to learn how it works under the hood as well as doing benchmarking & profiling to figure out why it has a high memory consumption.
+- We have been building a [proof-of-concept solution](https://github.com/sinzii/delightfuldot-poc/tree/main/src/poc) in an attempt to address the memory issue and saw a [clear/good improvement](https://github.com/sinzii/delightfuldot-poc/tree/main#memory-consumption-benchmark-result).
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 4.5 months
+- **Full-Time Equivalent (FTE):** 2 FTE
+- **Total Costs:** 30,000 USD
+
+### Milestone 1 — Foundational modules with core functionalities
+
+- **Estimated duration:** 3 months
+- **FTE:** 2
+- **Costs:** 17,000 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 to install `delightfuldot` and interact with Substrate-based networks. |
+| **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. |
+| 1. | Core functionalities | We'll build the following features for the library:
- New type system built on top of `scale-ts`
- A Metadata parser for the Substrate Metadata V14
- RPC APIs: Support default RPC APIs for Polkadot and Kusama networks & ability to add custom RPC APIs
- APIs to inspect pallets' constants
- APIs to execute pallets' storage queries
- APIs to inspect pallets' events & errors |
+| 2. | Publish to npm | We'll package and publish the library to npm, so developers can install and start using it.
+
+
+### Milestone 2 - More core functionalities
+
+- **Estimated Duration:** 1.5 months
+- **FTE:** 2
+- **Costs:** 13,000 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 to sign & submit extrinsics via `delightfuldot` and the migration process from `@polkadot/api` to `delightfuldot` |
+| **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. |
+| 1. | More core functionalities | We'll continue to build core functionalities for the library:
- APIs to create Extrinsics payload, sign and submit Extrinsics as well as the ability to keep watching for Extrinsic status after submission.
- Runtime APIs: Support default runtime APIs for Polkadot and Kusama networks & ability to add custom Runtime APIs
+
+## Future Plans
+
+Next steps for `delightfuldot` are:
+- Support APIs to interact with Smart Contract
+- Support older/newer versions of Metadata
+- Support more [RPC](https://polkadot.js.org/docs/substrate/rpc) and [Runtime](https://polkadot.js.org/docs/substrate/runtime) APIs
+- XCM utilities
diff --git a/applications/democratic-governance-1.md b/applications/democratic-governance-1.md
new file mode 100644
index 00000000000..a474a1a105d
--- /dev/null
+++ b/applications/democratic-governance-1.md
@@ -0,0 +1,187 @@
+# Democratic Governance 1
+
+- **Team Name:** Solidbit GmbH
+- **Payment Address:** CHF (22 November, 2023, 08:57 UTC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Encointer has started the development of a pallet that facilitates democratic voting based on Proof-Of-Personhood. We believe that this work can be a basis for Proof-Of-Personhood based governance protocols for varios applications such as DAOs or parachains, which could benefit from improved legitimacy when using a democratic over a plutocratic design. We are interested in building this project as it builds on top of our expertise with Proof-Of-Personhood and it lays an important foundation to facilitate non-plutocratic governance in Web3.
+
+### Project Details
+
+You can find the PR with the current state of the pallet [here](https://github.com/encointer/pallets/pull/273) and the node side of it [here](https://github.com/encointer/encointer-node/pull/350). There also exists a [documentation of the protocol](https://book.encointer.org/protocol-democracy.html) and a [tracking issue](https://github.com/encointer/pallets/issues/347) that tracks the work still to be done for the democracy pallet.
+
+In this project we will continue building the democracy pallet as well as improve the CLI and integration tests for the protocol. The following tasks will be implemented:
+
+- Decide which matters can be voted on and implement (1.5 days)
+- Use timestamps instead of blocks to be consistent with cycles (1.5 days)
+- Use reputation commitment pallet for proposals (0.5 days)
+- Pass proposal enactment errors to user (0.5 days)
+- Lazy proposal update (0.5 days)
+- Persist electorate size in proposal (0.5 days)
+- Add more events (0.5 days)
+- Refactor integrations tests to be independent and systematically cover all potantial voting scenarios (1 day)
+- Extend CLI (Show vote status, make enactments queriable) (1 day)
+- Tutorial (0.5 days)
+
+### Ecosystem Fit
+
+This project helps to build the foundation of a One-Person-One-Vote paradigm for varios governance systems in Web3. We believe that Proof-Of-Personhood and demorcatic voting will become essential in many Web3 applications, and thus Dotsama as a whole will profit from having a protocol like this available in the ecosystem.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Piero Guicciardi (Project Lead & Developer)
+- Alain Brenzikofer (Advisor Protocol)
+- Christian Langenbacher (Advisor Implementation)
+
+### Contact
+
+- **Contact Name:** Piero Guicciardi
+- **Contact Email:** pg@solid-bit.com
+- **Website:** https://solid-bit.com
+
+### Legal Structure
+
+- **Registered Address:** General Wille Strasse 99, CH-8706 Meilen, Switzerland
+- **Registered Legal Entity:** Solidbit GmbH (CHE-267.620.734)
+
+### Team's experience
+
+Piero has been a core protocol developer for [Encointer](https://github.com/encointer) for the last two years and has recently become a member of the Polkadot Technical Fellowship. Among other projects, he designed and implemented a democracy module on top of Encointer's persoonhood reputation system. Please check out the [pull request](https://github.com/encointer/pallets/pull/273) and the [high level documentation](https://book.encointer.org/protocol-democracy.html).
+
+Below you can find a list of other contributions by Piero:
+
+#### Encointer core protocol:
+- Design and implement faucet
+ - https://github.com/encointer/book/pull/14
+ - https://github.com/encointer/encointer-node/pull/333
+ - https://github.com/encointer/pallets/pull/319
+ - https://github.com/encointer/pallets/pull/326
+ - https://github.com/encointer/encointer-parachain/pull/193
+- Design and implement democracy module
+ - https://book.encointer.org/protocol-democracy.html
+ - https://github.com/encointer/pallets/pull/273
+- Redesign participant attestations
+ - https://github.com/encointer/pallets/pull/231
+ - https://github.com/encointer/pallets/issues/215
+- Endorsement after registration
+ - https://github.com/encointer/pallets/pull/202
+- Early reward payout
+ - https://github.com/encointer/pallets/pull/233
+- Allow for upgrading registrations and unregistering
+ - https://github.com/encointer/pallets/pull/254
+- Allow reputables to endorse
+ - https://github.com/encointer/pallets/pull/268
+- Geohash location validation algorithm
+ - https://github.com/encointer/pallets/pull/55
+- Constant time random permutation for meetup assignment
+ - https://github.com/encointer/pallets/pull/68
+
+#### Misc:
+- Implement custom RPCs
+ - https://github.com/encointer/pallets/pull/196
+- Implement storage migrations for Weight V2
+ - https://github.com/encointer/pallets/pull/308
+- Various polkadot/substrate dependency bumps
+ - https://github.com/encointer/pallets/pull/299
+ - https://github.com/encointer/encointer-parachain/pull/171
+- Fee payment in Encointer community currency
+ - https://github.com/encointer/encointer-node/pull/194/files
+ - https://github.com/encointer/encointer-node/pull/226
+ - https://github.com/encointer/pallets/pull/190
+- Integrate try runtime
+ - https://github.com/encointer/encointer-parachain/pull/177/files
+ - https://github.com/encointer/encointer-node/pull/312/files
+
+
+#### Non rust contributions:
+- Build an indexer using qubquery
+ - https://github.com/encointer/subquery (Main author)
+- Build an accounting tool for encointer businesses
+ - https://github.com/encointer/accounting-frontend (Main author)
+ - https://github.com/SolidbitGmbH/encointer-accounting-backend (Main author)
+- Build an integration for Encointer personhood in KILT
+ - https://github.com/encointer/kilt-personhood (Main author)
+- Contributions to encointer js
+ - https://github.com/encointer/encointer-js/pull/78
+
+
+The two project advisors Alain Brenzikofer and Christian Langenbacher both are known figures in the Dotsama ecosystem. Alain is the founder of [Encointer](https://github.com/encointer) and [Integritee](https://github.com/integritee-network) and Chris is the tech-lead of both of those projects.
+
+
+Encointer has previously received a W3F grant.
+
+
+### Team Code Repos
+
+- https://github.com/encointer/pallets
+- https://github.com/encointer/encointer-parachain
+- https://github.com/encointer/encointer-node
+- https://github.com/SolidbitGmbH/encointer-accounting-backend
+
+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/pifragile
+- https://github.com/brenzi
+- https://github.com/clangenb
+
+
+### Team LinkedIn Profiles
+
+- https://www.linkedin.com/in/piero-guicciardi-66b939152/
+- https://www.linkedin.com/in/alain-brenzikofer-9a4480165/
+- https://www.linkedin.com/in/christian-langenbacher-baa629182/
+
+
+## Development Status :open_book:
+
+You can find the PR with the current state of the pallet [here](https://github.com/encointer/pallets/pull/273) and the node side of it [here](https://github.com/encointer/encointer-node/pull/350). There also exists a [documentation of the protocol](https://book.encointer.org/protocol-democracy.html) and a [tracking issue](https://github.com/encointer/pallets/issues/347) that tracks the work still to be done for the democracy pallet.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 1 month
+- **Full-Time Equivalent (FTE):** 0.4 (8 person days)
+- **Total Costs:** 8320 CHF
+
+### Milestone 1 Example — Protocol enhancements
+
+- **Estimated duration:** 1 month
+- **FTE:** 0.4 (8 person days)
+- **Costs:** 8320 CHF
+
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | GPLv3
+| **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 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** in the Encointer book that explains the functionality of the democracy module.|
+| 1. | Democracy Pallet | We will implement the above described tasks in the Encointer democracy pallet. |
+| 3. | CLI and Integration Tests | We will implement the above described tasks in the CLI and extend the existing integration tests. |
+
+
+## Future Plans
+
+We will keep track of all future work in the [tracking issue](https://github.com/encointer/pallets/issues/347). The main vision is to build a protocol where Dotsama users can globally participate in governance using their personhood instead of their tokens. Already defined steps are:
+
+- Limit active proposals per reputable per cycle
+- Use generic dispatchables for proposal actions
+- Define protocol for inter-community voting
+
+## Referral Program (optional) :moneybag:
+
+- **Referrer:** Alain Brenzikofer: https://github.com/brenzi
+- **Payment Address:** 162yvHqgWxzb3rMWvEJyduQ72LHvkQNHVpvpASEWbhE8LwgT
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** I heard about it from Alain Brenzikofer.
diff --git a/applications/dot_etl.md b/applications/dot_etl.md
index e4fbf5ee1ce..ac7e79ee44a 100644
--- a/applications/dot_etl.md
+++ b/applications/dot_etl.md
@@ -8,7 +8,7 @@
### Overview
-This proposal is in response to the following RFP: [Analysis Website and Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/analysis-website-and-data-platform.md)
+This proposal is in response to the following RFP: [Analysis Website and Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/analysis-website-and-data-platform.md)
The goal of the Dot-ETL project is to lower the friction required to conduct fine-grained and aggregated analysis of transactions on Polkadot network, via a framework to extract Polkadot transaction-level data to various offline formats: e.g. CSV / delimited, relational, columnar. Furthermore, we intend to develop a framework to ETL Substrate to [Google BigQuery](https://cloud.google.com/bigquery), orchestrated via [Google Cloud Composer](https://cloud.google.com/composer).
diff --git a/applications/fidi-dotsight-analytics.md b/applications/fidi-dotsight-analytics.md
index d911dd5488b..f570a42b535 100644
--- a/applications/fidi-dotsight-analytics.md
+++ b/applications/fidi-dotsight-analytics.md
@@ -7,7 +7,7 @@
- **Payment Address:** 14fptYf88mjarGJ3gAjhd8YH3Cefdgx4C8Jb6chvJXFszb2i (USDT / Polkadot)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
-This project is a response to Keegan Quigley’s [RFP #1539](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/analysis-website-and-data-platform.md) inspired by Rob Habermeier’s Polkadot forum [post](https://forum.polkadot.network/t/dune-analytics-style-data-service-for-polkadot-kusama/271).
+This project is a response to Keegan Quigley’s [RFP #1539](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/analysis-website-and-data-platform.md) inspired by Rob Habermeier’s Polkadot forum [post](https://forum.polkadot.network/t/dune-analytics-style-data-service-for-polkadot-kusama/271).
### Overview
diff --git a/applications/grantmaster.md b/applications/grantmaster.md
index 4b6a142487e..8fb4ce7ab8b 100644
--- a/applications/grantmaster.md
+++ b/applications/grantmaster.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-This application is in response to the RFP [Grant Management Web Application](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/grant_management_webapp.md).
+This application is in response to the RFP [Grant Management Web Application](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/grant_management_webapp.md).
### Overview
@@ -146,7 +146,7 @@ Zaniyar Jahany is a Senior science associate at ZHAW (university of applied scie
## Development Status :open_book:
-This application is in reply to the RFP [Grant Management Web Application](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/grant_management_webapp.md).
+This application is in reply to the RFP [Grant Management Web Application](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/grant_management_webapp.md).
### Wireframes
@@ -169,13 +169,13 @@ To get a feeling how the page will look like, I prepared this Hi Fi wireframe. K
### Overview
-- **Total Estimated Duration:** 2 months
+- **Total Estimated Duration:** 5 months
- **Full-Time Equivalent (FTE):** 0.6 FTE
- **Total Costs:** 10,000 USD
### Milestone 1 — Development of API and Grant Frontend
-- **Estimated Duration:** 2 months
+- **Estimated Duration:** 5 months
- **FTE:** 0.6
- **Costs:** 10,000 USD
@@ -218,4 +218,4 @@ I'm planning to implement the following milestone as part of a possible follow-u
## Additional Information :heavy_plus_sign:
-**How did you hear about the Grants Program?** personal recommendation
\ No newline at end of file
+**How did you hear about the Grants Program?** personal recommendation
diff --git a/applications/hybrid.md b/applications/hybrid.md
index a8c7131e949..31585e29757 100644
--- a/applications/hybrid.md
+++ b/applications/hybrid.md
@@ -8,8 +8,8 @@
## Project Overview :page_facing_up:
This application is in response to two RFPs:
-- Multi-chain Block Explorer https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/multi-chain-block-explorer.md
-- ink! smart contract block explorer. https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/ink_smart_contract_block_explorer.md
+- Multi-chain Block Explorer https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/multi-chain-block-explorer.md
+- ink! smart contract block explorer. https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ink_smart_contract_block_explorer.md
### Overview
diff --git a/applications/hybrid_node_research.md b/applications/hybrid_node_research.md
index 6d488252b62..57e4d65b9cc 100644
--- a/applications/hybrid_node_research.md
+++ b/applications/hybrid_node_research.md
@@ -4,7 +4,7 @@
## Project Overview :page_facing_up:
-This grant application falls under this RFP https://github.com/w3f/Grants-Program/blob/master/docs/rfps/Open/alternative_polkadot_host_implementations.md and it is meant as a previous research work analysis before the actual rework of the host implementation.
+This grant application falls under this RFP https://github.com/w3f/Grants-Program/blob/master/docs/rfps/alternative_polkadot_host_implementations.md and it is meant as a previous research work analysis before the actual rework of the host implementation.
### Overview
diff --git a/applications/hyperfridge.md b/applications/hyperfridge.md
new file mode 100644
index 00000000000..7cc58e2585d
--- /dev/null
+++ b/applications/hyperfridge.md
@@ -0,0 +1,343 @@
+# Hyperfridge: A Trustless Bidirectional Bridge to Banking Networks
+
+- **Team Name:** element36 AG
+- **Payment Address:** 0x56788E08C97d2677DAdED801e69bfE5D33ddACD5 (DAI)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+Today blockchain and traditional ledgers (banks) are connected via "FIAT gateways" - through crypto exchanges or payment systems like Stripe which support Crypto. One remaining problem is, that we still can not "see" through the blockchain lens what is going on in traditional finance ledgers, e.g. we can not query the balance of a bank account on-chain (often referred as [information asymmetry](https://en.wikipedia.org/wiki/Information_asymmetry)). This disparity is surprising given the existence and standardisation of banking APIs. Furthermore, it's noteworthy that conventional financial systems also rely on cryptography to safeguard their APIs and to hash and sign their data.
+
+With our first grant delivery ([FIAT-on-off-ramp](https://github.com/w3f/Grants-Program/blob/master/applications/FIAT-on-off-ramp.md)) we are able to "look inside" a bank account, synchronise data and trigger new wire transfers on-chain. Now we propose to use Zero-Knowledge Proofs to validate the data without compromising on data privacy thus achieving *soundness* for the FIAT ramp. We claim to be trustless, because we validate bank-signatures and assume that banking ledgers can be trusted due to "proof of authority" (they are heavily audited and regulated). Thus the “ramp” becomes a “bridge” quite similar to what we use when (hyper) bridging different blockchain protocols. Hyperfridge can be run by anyone on their own hardware to connect their nodes to their own bank account without intermediaries.
+
+ We believe to be the first group who provides an open source solution stack to balance the information asymmetry between crypto and traditional finance in a non-centralized and non-SaaS-way without intermediaries, but cryptographically validated. The vision is to create a FIAT-utility para-chain which allows anyone to "plug-in" their own bank account to Polkadot and be able to write safe applications which can send and receive funds through the banking ledgers.
+
+
+Note: The submission relates to an RFP [ISO 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/ISO_20022.md).
+
+### Overview
+
+The aim of Hyperfridge is to create a trustless bridge between traditional banking networks to blockchains specifically to the Polkadot ecosystem. Our solution allows users to "plug in" their bank accounts into the Polkadot network, enabling bidirectional data exchange between the blockchain and the banking ledger with trustless assurance.
+
+Through the utilisation of zero-knowledge proofs, we establish a trustless oracle that validates and verifies transactions and activities associated with the "plugged" bank accounts. This technology facilitates secure settlements for purchasing or selling tokens in fiat, while extending its functionality to encompass a broader range of applications beyond mere transactions: Any smart contract can effortlessly trigger payments and respond to new transactions, essentially automating traditional fiat transactions on the blockchain. Our mission is to eliminate the need of centralised exchanges as intermediaries, providing users with the ability to leverage smart contracts without forcing users to convert their funds into cryptocurrencies. This will remove a barrier of adoption - many use cases would appreciate the finality of a ledger but can not expose themselves to the risk which comes with handling cryptocurrencies and private keys. In the end, hyperfridge works as a simple library which secures and transports information from a standardised banking API trustlessly onto the chain.
+
+Our backend-APIs are built upon highly standardised banking protocols ([Ebics](https://ebics.org), [SEPA](https://www.ecb.europa.eu/paym/integration/retail/sepa/html/index.en.html), [ISO20022](https://www.iso20022.org/) messages), making it easy to connect seamlessly with banking networks. Many applications, including bookkeeping, already utilise these APIs, often available at no cost or minimal fees from many banks. Hyperfridge embraces these standardised APIs, ensuring a user-friendly and cost-effective integration process available for free to Polkadot programmers. Noteworthy is that some banks are already supporting immediate settlement, which will likely become mandatory in the SEPA area for all banks. Hyperfridge would then be able to support interactive scenarios - e.g. enabling Fiat/Crypto Swaps in one go.
+
+Hyerfridge aims to be available as a free and open sourced library - and not just as a service or platform as it is today. Hyperfridge would further allow any project to run its own business logic to span both crypto and traditional finance, which we think would be unique. Crypto applications would not depend on intermediaries like Stripe or Crypto Exchanges to connect with traditional finance.
+
+### Project Details
+
+At this point we would like to point to our [whitepaper](https://github.com/element36-io/ocw-ebics/blob/main/docs/hyperfridge-draft.pdf). To understand the implementation strategy we need to go into some specific properties of the banking interfaces we are going to use.
+
+#### Fundamental properties of the banking interface (ISO20022 and Ebics)
+
+The basic idea is the following: Whenever the bank (the banking API) is transmitting documents, it sends its data with a signature - using [XML encryption standards](https://www.w3.org/TR/xmlenc-core1/). For example a response document for a daily statement of balance and transactions would contain a section like this:
+
+```xml
+
+
+ ...
+
+ Z53 ...
+
+
+ __some_base64_=
+ __some_base64_=
+ ...
+ ...
+
+
+
+
+
+
+
+
+
+
+
+ PQxx__some_base64_aaaa=
+
+
+ __some_base64_
+
+
+
+```
+
+A wrapped Z53 document containing the daily statement showing 30191.23 as CHF balance would look similar to this:
+
+```xml
+
+
+ 5e9ea1005fe64f1b924e968898bcfa7c
+ 146
+ 2023-06-30T19:24:46.387
+ CH4323432442432537312
+ 30191.232023-06-30
+ ...
+
+
+```
+
+The hash of the (zipped) Z53 documents needs to be validated with the data given in the ebicsRequest. "X002" refers to RSA signature key with a key length of 2048 bits, "E002" defines RSA algorithm for encryption using ECB (Electronic Codebook) and PKCS#1 v1.5 padding ([Also see here](https://www.ibm.com/docs/en/b2b-integrator/5.2?topic=eckf-managing-certificates-keys-users)) or take a look at standardization page on [Ebics](https://www.ebics.org/en/home) and [ISO20022](https://www.iso20022.org/) or a better readable [national page](https://www.six-group.com/dam/download/banking-services/standardization/ebics/market-practice-guidelines-ebics3.0-v1.2-en.pdf). Remark: A typical question is "what is the difference between Ebics and ISO20022?" An analogy might be that EBICS is to ISO20022 what HTTP is to HTML; that is, EBICS serves as the communication protocol while ISO20022 defines the message format structure.
+
+We use zero-knowledge proofs (circuits) to check signatures so that we do not have to publish bank statements, because this would reveal identities of transactions in clear-text. This allows us to veryfiy the data and its claim (a certain balance in our case). It is trustless to the extend that we use both secrets of the bank and the account owner to generate the proof (MPC - multi-party-computation).
+
+Now we can shift the trust from the bank account owner to the bank itself. But can we trust the keys of the bank? Here we would rely on the processes and the key ceremonies between a bank and its client and between a bank and its national bank. Hashes of banks are published - just google for *ebics hash*. Note that each bank uses [same keys for the communication with their clients and their respective national bank](https://www.bundesbank.de/resource/blob/868928/0d72f44f05be86cf78de84138a73d837/mL/verfahrensregeln-ebics-2021-data.pdf). Thus we only need to trust the top of the authorities, not individual banks. Thus the trust can be moved further up to the nation authorities who are auditing its nations' banks.
+
+But can we trust a nation or a government? The nations are monitored and measured by an independent international organisation called [FATF](https://www.fatf-gafi.org/en/home.html) who is responsible in setting worldwide standards on anti-money-laundering and evaluates the execution of these standards [regularly](https://www.fatf-gafi.org/en/publications/Mutualevaluations/Assessment-ratings.html) for each nation, which are usually [incorporated into local (e.g. Swiss) financial regulations](https://www.finma.ch/en/finma/international-activities/policy-and-regulation/fatf/). A system like hyperfridge can easily exclude certificates from banks from high risk countries.
+
+To sum up: Even if you are not trusting the banking system or governments; technically hyperfridge is "as good as it can get" for integrating the traditional system on a zero-trust basis. We do not aim to improve the legacy banking systems but use protocols with a wide adoption.
+
+For this grant we would aim at implementing *step α* of the [whitepaper](https://github.com/element36-io/ocw-ebics/blob/main/docs/hyperfridge-draft.pdf). This includes validation of account balance and validating hash and signature of the bank within the ZKP. This already creates a trustless information-exchange setup with the account holder. But we will not aim for *step β* of the paper to prove "transaction inclusion". An example for transaction inclusion is that the bank statement contains a transaction which shows that Alice has sent 5 CHF to the bank account- again without revealing any transaction data publicly. Reason is that we do not want to overload the delivery with complexity and we still at the beginning of your zero-knowledge learning curve.
+
+#### Proof system implementation
+
+As a library we will use [Risk-Zero](https://www.risczero.com/). Reasons are:
+
+- The risc0-verifier got [formally](https://www.github.com/risc0/risc0-lean4) verified.
+- It allows complex computing (e.g. unzipping files) with existing libraries using its Risc-5 architecture. It would be much harder to use a [Rank-1 constraint system](https://www.zeroknowledgeblog.com/index.php/the-pinocchio-protocol/r1cs) like [Circom](https://docs.circom.io/).
+- Its an actual ZKP library written in Rust and supporting 'no_std'.
+- It is based on STARKs (not SNARKs as the Hyperfridge paper suggests). SNARKs are cheap to validate (therefore good for EVM based systems) but the of STARKs be can automated (non-interactive). As we use Off-Chain-Workers the disadvantages of SNARKs do not matter for us and we can benefit from an easy setup to reach a "trustless" state.
+- But Risk-Zero provided a framework to wrap the STARK in a SNARK which can be validated with EVM based Smart Contracts.
+- Risk-Zero is very efficient - which is important if we want to process large XML documents. We expect that generating a single proof based on an XML document could take several hours without [CUDA](https://en.wikipedia.org/wiki/CUDA) acceleration or using [Bonsai](https://dev.risczero.com/bonsai).
+- Risk-Zero supports hardware acceleration and is offering validation as-a-service, which lowers adaption complexity.
+- We had first experiences with working with it (a proof-of-reserve system for a bank) and we like the fact to be able to implement our circuits in Rust rather than another language.
+
+As disadvantages we see:
+
+- Still a young framework - limitations (e.g. new ZK-vm version would likely require new proofs) and unstable APIs, especially "waiting time" for library developments need to be taken into account.
+- Potentially high proofing time; but we only need one proof a day.
+- Proof-size: Proof size may be too large for on-chain verification; This can be solved by snarking the STARK which would be likely solved by risc-zero framework, which we would include at a later stage.
+
+
+The library will be used generate the proof on our bankend to create a *receipt* - a document which contains the proof. We will change the existing Off-Chain-Worker (OCW) crate to validate the receipt before updating any state of the OCW. See [risk zero proofing system](https://dev.risczero.com/proof-system/) for details.
+
+Specification of proof system (see [Hyperfridge whitepaper](https://github.com/element36-io/ocw-ebics/blob/main/docs/hyperfridge-draft.pdf) for more details):
+
+- Secret input: Ebics envelope as XML and Z53/Camt53 as ZIP binary. See XMLs above.
+- Public input: Public Certificate of the Bank or name of bank, bank account number, balance and date.
+
+The prof system consists of (see [for details](https://dev.risczero.com/proof-system/proof-system-sequence-diagram)):
+
+- The circuit (for risk-zero an ELF lib) including its hash.
+- Client code which generates a Receipt (ZKP) as a modification to the [Ebics-Backend](https://github.com/element36-io/ebics-java-service) from our first grant.
+- The modifications of the [FIAT-ramp Off-Chain-Worker](https://github.com/element36-io/ocw-ebics/blob/main/INSTRUCTIONS.md) which validates the receipt.
+
+#### Other areas of implementation
+
+Our first grant contained a stable coin as an application for the FIAT-on-off ramp. We adapt this use case for mint (on-ramp), burn (off-ramp) and adapt units tests. UIs will provide access to receipts for self-validation.
+
+### Ecosystem Fit
+
+The information asymmetry is an important topic in the whole blockchain ecosystem, especially when integrating crypto- with traditional finance - think of FTX, Tether etc. It means that traditional finance is considered a black box, and can not be integrated like we would typically bridge blockchain protocols on a pure technical layer in a trustless manner. What is often overlooked here is that also traditional finance widely uses standardised APIs and messages, secured by digests and signatures to exchange data - very similar to blockchain protocols. Our library will use and validate the data provided (and digitally signed) by banks - means that anyone with a regular bank account is now able generate proof of balance or transactions to a ledger. The bank account owner is not able to generate those proofs without the bank's signature. We think we can add relevant delivery to closing the gap of information asymmetry by providing our library to the public.
+
+Every stage of the journey to integrate traditional finance into the crypto world will create value for the connecting protocol, because it is possible to enable new use cases and bring value into the system. Employing zero-knowledge proofs to ensure the trustlessness of these bridges represents a groundbreaking initiative, paving the way for potential blueprints for future projects. The unique aspect of our approach lies in our objective. We are not seeking to establish a contract or parachain-based system, akin to projects like Soracard or Stripe. Rather, our goal is to openly share our source code as infrastructure, detailing how to securely connect to banking networks in a trustless manner.
+
+The same principles can extend to the Financial Information eXchange protocol [(FIX)](https://en.wikipedia.org/wiki/Financial_Information_eXchange), which provides standardised messages for asset management. This opens the possibility to establish bidirectional and trustless bridges for entire asset portfolios (e.g automated tokenized ETFs or treasury bills) onto the blockchain.
+
+#### Similar Projects
+
+[Stripe](Stripe.com): is a leading traditional payment provider typically used by webshops all over the world. It solves the problem of companies receiving payments from anywhere in the world. Stripe is including blockchain use-cases as well: “Web3 companies can now direct customers to a Stripe-hosted onramp to buy cryptocurrencies.” [Stripe Fiat-to-Crypto-onramp](https://stripe.com/en-dk/newsroom/news/fiat-to-crypto-onramp). Hyperfridge would allow Web3 companies to replace stripe on the frontend with QR code as a payment gateway reducing fees from up to 3 % of stripe to 0 % with hyperfridge. But more importantly hyperfridge allows to consume events (payouts from stripe) and trigger payments on-chain and trustless.
+
+[Soracard](https://soracard.com/): Polkaswap offers to connect Soracard to your wallets. Its basically a bank offering an account, which allows you to on- and offramp crypto with payments directly to your Sora bank account. Hyperfridge is a library (not a platform or bank) which allows you to implement functionality like Sora offers. Hyperfridge could be used with a Sora bank account to consume events on the bank account if they offer ISO20022 compliance messages; but only banks in the EU are obliged to support API based banking.
+
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+* Leader: Walter Strametz, CTO Sygnum Bank, founder element36.io: Worked on roughly a dozen blockchain projects in Switzerland - among them building world's first digital asset bank ([Sygnum AG](https://sygnum.com)).
+* Dastanbek Samatov: Senior Rust Engineer with 3 years of experience in Substrate. Worked as a core developer in a couple of parachain teams and was part of multiple Web3 Foundation grants. See more in [Team's Experience](#teams-experience) section.
+* Vladimir Nicolic, Full Stack Developer: Javascript Senior, worked on decentral identity, large parts of the element36 modules and the Dapp for the exchange and compliance-administration.
+* Nicolas Le Bel, Cryptograph: Working full-time on zero-knowledge systems and once peer with Walter at Sygnum bank. He is advising us on architectural decisions especially regarding the proof system.
+
+We are in touch with [Risc-Zero](https://risczero) team who will support us with reviews, technical support at access to the [Bonsai](https://dev.risczero.com/bonsai) as proof-generation-system via their API.
+
+### Contact
+
+- **Contact Name:** Walter Strametz
+- **Contact Email:** walter.strametz@element36.io
+- **Website:** https://element36.io
+
+### Legal Structure
+
+- **Registered Address:** Bahnmatt 25, CH-6340 Baar, Zug,Switzerland
+- **Registered Legal Entity:** element36 AG, [CHE-180.390.659](https://zg.chregister.ch/cr-portal/auszug/auszug.xhtml?uid=CHE-180.390.659)
+
+### Team's experience
+
+We have already submitted a grant project successfully meeting standard and requirements: [FIAT-on-off-ramp](https://github.com/w3f/Grants-Program/blob/master/applications/FIAT-on-off-ramp.md). The project is also linked under the [RFP section](https://grants.web3.foundation/docs/RFPs/ISO_20022).
+
+Walter (and element36) a fully pegged ERC-20 stable-coin (EUR, CHF) and an exchange based on Ethereum, has extensive experience in the financial industry and is currently CTO of Sygnum Bank, a Swiss Crypto Bank. Dastan implemented the Substrate part of the last grant - a [FIAT-on-off-ramp](https://github.com/element36-io/ocw-ebics), which this grant is building upon. Nicolas will support us especially on the architecture level of the ZK proof system.
+
+Here is the list of relevant repos:
+
+Walter:
+
+- [Fiat-on-off-ramp, backend](https://github.com/element36-io/ebics-java-service)
+- [Eth-Stablecoin](https://github.com/element36-io/cash36-contracts)
+- [Frontend (Exchange for Stablecoin](https://github.com/element36-io/cash36-exchange)
+- [Usage Examples for Stablecoin](https://github.com/element36-io/cash36-examples)
+
+Dastan:
+
+- [Fiat-on-off-ramp](https://github.com/element36-io/ocw-ebics).
+- [ISO-8583](https://github.com/w3f/Grants-Program/pull/1809)
+- [Subsemly](https://github.com/LimeChain/subsembly).
+- [Runtime in Assemblyscript](https://github.com/LimeChain/as-substrate-runtime).
+- [SCALE CODEC](https://github.com/LimeChain/as-scale-codec)
+
+### Team Code Repos
+
+- https://github.com/element36-io/ocw-ebics: The off-chain worker of our first grant [FIAT-on-off-ramp](https://github.com/w3f/Grants-Program/blob/master/applications/FIAT-on-off-ramp.md).
+- https://github.com/element36-io/ebics-java-service: A wrapper for bank-APIs where we will integrate the ZKP.
+- https://github.com/element36-io/ocw-ebics/blob/main/docs/hyperfridge-draft.pdf: The hyperfridge whitepaper discussing the concept.
+
+### Team LinkedIn Profiles (if available)
+
+- [Walter](https://www.linkedin.com/in/walter-strametz-6b44618b/)
+- [Dastan](https://www.linkedin.com/in/dastanbek-samatov-30ab71128/)
+- [Nicolas](https://www.linkedin.com/in/nicolas-le-bel/)
+
+## Development Status :open_book:
+
+Relates to RFP: [ISO 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/ISO_20022.md).
+
+Repos:
+
+- https://github.com/element36-io/ocw-ebics: The off-chain worker of our first grant [FIAT-on-off-ramp](https://github.com/w3f/Grants-Program/blob/master/applications/FIAT-on-off-ramp.md).
+- https://github.com/element36-io/ebics-java-service: A wrapper for bank-APIs where we will integrate the ZKP.
+- https://github.com/element36-io/ocw-ebics/blob/main/docs/hyperfridge-draft.pdf: The hyperfridge whitepaper discussing the concept.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 6 months, 5 milestones
+- **Full-Time Equivalent (FTE):** 1.5 FTE
+- **Total Costs:** USD 30'000
+
+### Milestone 1 - Risk-Zero ZKP implementation based on static test data
+
+- **Estimated duration:** 2 month
+- **FTE:** 1.5
+- **Costs:** 12,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | We will provide both inline documentation of the code, a basic tutorial and a markdown description of the proof system. |
+| 0c. | Testing Guide | Provide unit tests of core functions and test data to ensure functionality. 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. |
+| 1a. | risc0 Guest Program | Code (circuit) to generate the proof, later used by the proving system. Secret input of [Guest Program](https://dev.risczero.com/terminology#guest-program): Ebics envelope as XML and Z53/Camt53 file(s) as ZIP binary - see XML examples above. The Public input is: Public Certificate of the Bank or name of bank, bank account number, balance and date. The [journal](https://dev.risczero.com/terminology#journal) will contain balance, currency, timestamp in the ebics-envelope, timestamp of the proof, client-account-number, Bank-ID and sequence number of the bank-statement. The circuit will check the hash of the (zipped) Z53 documents and compares it with the data given in the ebicsRequest. It checks the signature of the Ebics request and the signed hash of the ZIP file using crypto standards X002 and E002. "X002" refers to RSA signature key with a key length of 2048 bits, "E002" defines RSA algorithm for encryption using ECB (Electronic Codebook) and PKCS#1 v1.5 padding.|
+| 1b. | Generate Receipt | Generate [receipt](https://dev.risczero.com/terminology#receipt) which proves that the computation (e.g. balance) is correct and signed by the bank. |
+| 1c. | Validator | Code to validate the receipt. |
+| 1d. | Hyperfridge Crate | The crate to create and validate recipes (ZKPs), wrapping the functionality. |
+| 2. | Unit Tests | We will add unit tests and test data for creating and validating proofs which includes edge cases like wrong balance claims or faulty signature of the bank. |
+| 3. | Performance Benchmark | Present a table with performance metrics, so that hyperfride proofing times can be interpolated with data from [risc-zero](https://dev.risczero.com/datasheet.pdf). |
+
+
+### Milestone 2 - Banking API Integration
+
+- **Estimated duration:** 1 month
+- **FTE:** 1.2
+- **Costs:** 5,000 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 start the backend and send test transactions, which will show how the new functionality works.|
+| 0c. | Testing Guide | Adapt unit tests of core functions and test data to ensure functionality and robustness of the overall system (bridge and proofs). 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. | Generate Receipt | Retrieve data form backend and generate receipt (proof) using the proving system. |
+| 2. | Provide API | We will provide an application based on Spring-Boot that will contain `getBankstatements():Statement[]` (which includes account balance), `createOrder (OutgoingPayment)` and `simulatePayment(Payment)` as a REST interface as [described](#b-bank-account-rest-api). The recipe data is added in the [backend API](http://w.e36.io:8093/ebics/swagger-ui/?url=/ebics/v2/api-docs/#/) `/ebics/api-v1/bankstatements`` with two new fields in the top level of the JSON-response: `risc0Recipe:base64` and `risc0Hash:base64` as its hash so that clients can use a public verifier. |
+| 3. | Provide Banking-UI | Show a UI to see the status of banking backend (show accounts, transactions etc). We will use [LibEuFin](https://github.com/element36-io/ebics-java-service/blob/main/docs/SANDBOX.md) - same as in our first grant. |
+| 4. | Unit Tests | We will adapt unit tests and test data to cover creating and validating proofs. |
+| 5. | Repository | Repository will be the existing repo [ebics-java-service](https://github.com/element36-io/ebics-java-service) |
+| 6. | Backend-Docker | Provide docker-compose images for setting up banking API wrapper, LibEuFin proxy for banking-API. Set up test data in the backend via script and run tests which include the proving system. |
+| 7. | Swagger | Provide Swagger docu for the backend. |
+
+
+### Milestone 3 - Integration into fiat-ramp pallet
+
+- **Estimated duration:** 1 month
+- **FTE:** 1.2
+- **Costs:** 5,000 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 integrate hyperfridge and send test transactions, which will show how the new functionality works. |
+| 0c. | Testing Guide | Adapt unit tests of core functions and test data to ensure functionality and robustness of overall system (bridge and proofs). 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. | Integrate Receipt | Code to integrate the validitator in the Off-Chain Worker: when synchronising using following steps: a) poll the bank account for incoming (new) bank transactions and initiate `mint` transactions accordingly if proof validades. b) Listen for burn-events for stablecoins on our substrate chain to initiate outgoing transactions on our bank account. c) Use local storage to map between bank account and wallet or contract address for the mint and burn. Enter a "suspended" state if validation fails until a valid proof arrives. As validator either use own code or - if available - [universal rollup](https://dev.risczero.com/litepaper#solution) and Bonsai validator . |
+| 2. | fiat-ramp pallet | Code will be found in [fiat-pallet](https://github.com/element36-io/ocw-ebics/tree/main/pallets/fiat-ramps). |
+| 3. | Unit Tests | We will adapt unit tests and test data to cover creating and validating proofs. |
+
+
+### Milestone 4 - Node with stable-coin application
+
+
+- **Estimated duration:** 1 month
+- **FTE:** 1.5
+- **Costs:** 7,000 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 spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. |
+| 0c. | Testing Guide | Adapt unit tests of core functions and test data to ensure functionality and robustness of overall system (bridge and proofs). 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. | Stablecoin App | Change stablecoin implementation include validating the proof for mint, burn and updates on the FIAT-bridge. Failed validating leads to breaking operations issuing a "validation failed" events. |
+| 2. | fiat-ramp node | Code will be found in [fiat-node](https://github.com/element36-io/ocw-ebics/tree/main/node) part of the repo. |
+| 3. | Unit Tests | We will adapt unit tests and test data to cover creating and validating proofs. |
+| 4. | Whitepaper| Update the hyperfridge whitepaper with new learnings and description of the implementation. |
+| 5. | API| Update the hyperfridge whitepaper with new learnings and description of the implementation. |
+
+
+### Milestone 5 Demo-UI with stable-coin application
+
+* **Estimated Duration:** 1 month
+* **FTE:** 0.5
+* **Costs:** 1.000 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 start the UI and send test transactions, which will show how the new functionality works. |
+| 0c. | Testing Guide | Adapt unit tests of core functions and test data to ensure functionality and robustness of overall system (bridge and proofs). 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 hyperfridge. |
+| 1a. | Buy me a coffee dApp | Same as in our first grant, but with ZKPs: DApp where users can accept donations in stablecoin or via bank transfer, making receipts available for self-validation. This will consist of a frontend app in React which serves as an interface for interacting with the chain. Users will be able to link their on-chain `AccountId` to their bank account details (IBAN, balance, etc.), withdraw on-chain balance to their bank account and transfer funds in the bank account via on-chain extrinsic. |
+| 1b. | Proof-Download | UI will provide Proof data and instructions, so that anyone can check the proofs offline by themselves, without UI. |
+| 2. | Docker-Compose: node & Dapp | We will add the Dapp to the docker-compose file of previous Milestones to demonstrate the full functionality of our chain, the ocw, including a proxy for the FIAT Rest Interface. |
+
+
+## Future Plans
+
+In the short term, our primary focus is on the challenging task of implementing and refining the Zero-Knowledge Proofs (ZKPs). As immediate follow-up we see:
+
+- If needed (smaller proofs), snarking the Risc0 Stark of this grant for on-chain verification.
+- Adding proofs for *transaction inclusion*, as discussed in the whitepaper. Risc0 is finalising its work on ["sub-proofs"](https://www.risczero.com/news/continuations) which will likely allow an efficient implementation for generating a separate proof for each transaction.
+- Risc0 is working on a general on-chain validator and an ecosystem to make it easy for applications to integrate.
+- Having the above features we see a compelling case for a para-chain.
+
+
+
+We plan to showcase our progress at select events and conferences (sub0, Polkadot decoded or Meetups). The team of risc0 is very supportive and they see our implementation as a strong use-case for their libraries. [Polymec](https://parachains.info/details/polimec) is strongly interested in using the system. We maintain a strong relationship with Crypto-operating banks in Switzerland.
+
+## Referral Program (optional) :moneybag:
+
+None.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?**: Web3 Foundation Website
+
+Additional information:
+
+- Note the grant we have submitted [FIAT-on-off-ramp](https://github.com/w3f/Grants-Program/blob/master/applications/FIAT-on-off-ramp.md).
+- There are no other financial contributions other than our own and the one from our first grant.
+- We did not apply to any other grant, but - if we are successful with this - we look into implementing a EVM validator based on SNARKs which are able to validate Receipts generated with the codebase and runtimes of this grant.
diff --git a/applications/index.md b/applications/index.md
index 6c8658a5f74..dda67b2a9e8 100644
--- a/applications/index.md
+++ b/applications/index.md
@@ -6,93 +6,136 @@ layout: applications
Use this page for an overview of all public grants and their status. Use the sidebar to navigate directly to a specific grant application document.
:::info
+This page provides an overview of accepted grant applications, their progress, and a link to their GitHub repositories. In cases where the link points to an organization, you should be aware that the grant application itself **is often an independent project unrelated to other work done by the teams**.
-This page provides an overview of accepted grant applications, their progress and a link to their GitHub repositories. In cases where the link points to an organization, you should be aware that the grant application itself **is often an independent project unrelated to other work done by the teams**.
-
-Furthermore, the page lists terminations which happened due to a breach of the terms of the grants programs. Additionally, teams might have decided to stop working on the grant—though not necessarily on the project itself—for various reasons, which is not reflected on this sheet.
+Furthermore, the page lists terminations that happened due to a breach of the terms of the grants programs. Additionally, teams might have decided to stop working on the grant—though not necessarily on the project itself—for various reasons, which is not reflected on this sheet.
Besides, **there is a clear difference between an application being accepted and the successful delivery of the respective project**, and only teams that have successfully delivered a milestone are allowed to make public announcements on the matter or to use our [badge](https://github.com/w3f/General-Grants-Program/blob/master/grants/grant-badge-guidelines.md). The badge can also never be used as a general endorsement for a team. Violations to this policy can be reported [here](mailto:grants@web3.foundation).
-
:::
+
+
+- [2024](#2024)
+ - [🏄 Wave 21 - Q1 2024](#-wave-21---q1-2024)
- [2023](#2023)
- - [🏄 Wave 19 - Q3 2023](#️-wave-19---q3-2023)
- - [🏄 Wave 18 - Q2 2023](#️-wave-18---q2-2023)
- - [🏄 Wave 17 - Q1 2023](#️-wave-17---q1-2023)
+ - [🏄 Wave 20 - Q4 2023](#-wave-20---q4-2023)
+ - [🏄 Wave 19 - Q3 2023](#-wave-19---q3-2023)
+ - [🏄 Wave 18 - Q2 2023](#-wave-18---q2-2023)
+ - [🏄 Wave 17 - Q1 2023](#-wave-17---q1-2023)
- [2022](#2022)
- - [🏄 Wave 16 - Q4 2022](#️-wave-16---q4-2022)
- - [🏄 Wave 15 - Q3 2022](#️-wave-15---q3-2022)
- - [🏄 Wave 14 - Q2 2022](#️-wave-14---q2-2022)
- - [🏄 Wave 13 - Q1 2022](#️-wave-13---q1-2022)
+ - [🏄 Wave 16 - Q4 2022](#-wave-16---q4-2022)
+ - [🏄 Wave 15 - Q3 2022](#-wave-15---q3-2022)
+ - [🏄 Wave 14 - Q2 2022](#-wave-14---q2-2022)
+ - [🏄 Wave 13 - Q1 2022](#-wave-13---q1-2022)
- [2021](#2021)
- - [🏄 Wave 12 - Q4 2021](#️-wave-12---q4-2021)
- - [🏄 Wave 11 - Q3 2021](#️-wave-11---q3-2021)
- - [🏄 Wave 10 - Q2 2021](#️-wave-10---q2-2021)
- - [🏄 Wave 9 - Q1 2021](#️-wave-9---q1-2021)
+ - [🏄 Wave 12 - Q4 2021](#-wave-12---q4-2021)
+ - [🏄 Wave 11 - Q3 2021](#-wave-11---q3-2021)
+ - [🏄 Wave 10 - Q2 2021](#-wave-10---q2-2021)
+ - [🏄 Wave 9 - Q1 2021](#-wave-9---q1-2021)
- [2020](#2020)
- - [🏄 Wave 8 - Q4 2020](#️-wave-8---q4-2020)
- - [🏄 Wave 7 - Q3 2020](#️-wave-7---q3-2020)
- - [🏄 Wave 6 - Q2 2020](#️-wave-6---q2-2020)
- - [🏄 Wave 5 - Q1 2020](#️-wave-5---q1-2020)
+ - [🏄 Wave 8 - Q4 2020](#-wave-8---q4-2020)
+ - [🏄 Wave 7 - Q3 2020](#-wave-7---q3-2020)
+ - [🏄 Wave 6 - Q2 2020](#-wave-6---q2-2020)
+ - [🏄 Wave 5 - Q1 2020](#-wave-5---q1-2020)
- [2019](#2019)
- - [🏄 Wave 4 - Q4 2019](#️-wave-4---q4-2019)
- - [🏄 Wave 3 - Q3 2019](#️-wave-3---q3-2019)
- - [🏄 Wave 2 - Q2 2019](#️-wave-2---q2-2019)
- - [🏄 Wave 1 - Q1 2019](#️-wave-1---q1-2019)
+ - [🏄 Wave 4 - Q4 2019](#-wave-4---q4-2019)
+ - [🏄 Wave 3 - Q3 2019](#-wave-3---q3-2019)
+ - [🏄 Wave 2 - Q2 2019](#-wave-2---q2-2019)
+ - [🏄 Wave 1 - Q1 2019](#-wave-1---q1-2019)
+
+## 2024
+
+### 🏄 Wave 21 - Q1 2024
+
+| Team | Project | Link | Terminated | First Delivery | Completed |
+| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------| :---------: | :------------: | :--------: |
+| [MLabs](https://mlabs.city/) | [TuxedoDapp](./TuxedoDapp.md) | [GitHub](https://github.com/mlabs-haskell) | ☐ | ☐ | ☐ |
## 2023
+### 🏄 Wave 20 - Q4 2023
+
+| Team | Project | Link | Terminated | First Delivery | Completed |
+| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------| :---------: | :------------: | :--------: |
+| [Farcloud-labs](https://github.com/YanOctavian) | [SubSMT](./subsmt.md) | [GitHub](https://github.com/YanOctavian) | ☐ | ☐ | ☐ |
+| [Livetree Community Ltd](https://github.com/livetreetech/) | [DecentralML](./decentral_ml.md) | [GitHub](https://github.com/livetreetech/) | ☐ | ☐ | ☐ |
+| [LimeChain](https://github.com/LimeChain) | [Polkadot Protocol Conformance Tests Research](./Polkadot-Protocol-Conformance-Tests.md) | [GitHub](https://github.com/LimeChain) | ☐ | ☒ | ☒ |
+| [KodaDot](https://kodadot.xyz/) | [AssetsHub NFT indexer](./kodadot_assethub_nft_indexer_statemine_statemint.md) | [GitHub](https://github.com/kodadot) | ☐ | ☐ | ☐ |
+| [Apollos Collective](https://rhys.tech) | [Infimum](./infimum.md) | [GitHub](https://github.com/rhysbalevicius) | ☐ | ☐ | ☐ |
+| [CoinFabrik](https://www.coinfabrik.com/) | [CoinFabrik On Ink Integration Tests 2](CoinFabrik_On_Ink_Integration_Tests_2.md) | [GitHub](https://github.com/CoinFabrik) | ☐ | ☒ | ☒ |
+| [Plutonication](https://github.com/cisar2218/Plutonication) | [Plutonication](Plutonication.md) | [GitHub](https://github.com/cisar2218/Plutonication) | ☐ | ☒ | ☐ |
+| [gmajor](https://github.com/gmajor-encrypt) | [JsonRpsee socks5 proxy](JsonRpsee-socks5-proxy.md) | [GitHub](https://github.com/gmajor-encrypt) | ☐ | ☐ | ☐ |
+| [ParaSpell](https://github.com/paraspell) | [SpellRouter](SpellRouter-proposal.md) | [GitHub](https://github.com/paraspell) | ☐ | ☐ | ☐ |
+| [Paraverse Foundation](https://talisman.xyz) | [Signet - Talisman](signet.md) | [GitHub](https://github.com/TalismanSociety) | ☐ | ☒ | ☐ |
+| [Libeccio Labs](https://github.com/LibeccioLabs) | [Tux0](tux0.md) | [GitHub](https://github.com/LibeccioLabs) | ☐ | ☐ | ☐ |
+| [PolkaGate](https://polkagate.xyz) | [PolkaMask](polkamask.md) | [GitHub](https://github.com/PolkaGate) | ☐ | ☐ | ☐ |
+| [Mansa Capital](https://mansacapital.us/) | [Ssal](ssal-commods-dex.md) | [GitHub](https://github.com/MatteoPerona/Riso) | ☐ | ☐ | ☐ |
+| [Deitos Network](https://github.com/Deitos-Network) | [Deitos Network](Deitos_Network.md) | [GitHub](https://github.com/Deitos-Network) | ☐ | ☐ | ☐ |
+| [Lastic](https://www.lastic.xyz/) | [Coretime Sale Price Calculator](lastic-price-simulation-2.md) | [GitHub](https://github.com/LasticXYZ/price-simulation) | ☐ | ☒ | ☒ |
+| [Tokenguard.io](http://tokenguard.io/) | [Tokenguard](Tokenguard.md) | [GitHub](https://github.com/tokenguardio) | ☐ | ☐ | ☐ |
+| [element36 AG](https://element36.io) | [Hyperfridge](hyperfridge.md) | [GitHub](https://github.com/element36-io) | ☐ | ☐ | ☐ |
+| [RegionX](https://regionx.tech) | [RegionX](RegionX.md) | [GitHub](https://github.com/RegionX-Labs) | ☐ | ☐ | ☐ |
+| [WeTEE DAO](https://www.wetee.app) | [WeTEE Network](WeTEE_Network.md) | [GitHub](https://github.com/wetee-dao) | ☐ | ☐ | ☐ |
+| [CoinFabrik](https://www.coinfabrik.com/) | [CoinFabrik On Ink Integration Tests 3](CoinFabrik_On_Ink_Integration_Tests_3.md) | [GitHub](https://github.com/CoinFabrik) | ☐ | ☒ | ☒ |
+| [Andrea Di Franco](https://github.com/andredif) | [QuantumGuard](quantum-guard.md) | [GitHub](https://github.com/andredif) | ☐ | ☐ | ☐ |
+| [Solidbit GmbH](https://solid-bit.com) | [Democratic Governance](democratic-governance-1.md) | [GitHub](https://github.com/encointer) | ☐ | ☒ | ☒ |
+| [Auguth Tech](https://github.com/auguth) | [Proof of Contract Stake (Pallet)](PoCS.md) | [GitHub](https://github.com/auguth/pocs) | ☐ | ☐ | ☐ |
+
+[🔝](#top)
+
### 🏄 Wave 19 - Q3 2023
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------| :--------- | :------------: | :--------: |
-| [Protofire](https://protofire.io/) | [Contract Wizard](./Contract_wizard.md) | [GitHub](https://github.com/protofire/polkadot-contract-wizard/) | ☐ | ☐ | ☐ |
-| [ZeroDAO](https://github.com/ZeroDAO) | [Melodot](./Melodot.md) | [GitHub](https://github.com/ZeroDAO) | ☐ | ☒ | ☐ |
+| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------| :---------: | :------------: | :--------: |
+| [Protofire](https://protofire.io/) | [Contract Wizard](./Contract_wizard.md) | [GitHub](https://github.com/protofire/polkadot-contract-wizard/) | ☐ | ☒ | ☒ |
+| [ZeroDAO](https://github.com/ZeroDAO) | [Melodot](./Melodot.md) | [GitHub](https://github.com/ZeroDAO) | ☐ | ☒ | ☒ |
| [Starks](https://github.com/tur461) | [XCM tool for NFTs](./xNFT.md) | [GitHub](https://github.com/tur461) | ☐ | ☐ | ☐ |
-| [ChainSafe](https://chainsafe.io/) | Polkadot Snap Maintenance | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☐ | ☐ |
-| [justmert](https://github.com/justmert) | [DOTLY: Revolutionizing Polkadot Account Statistics](./dotly.md) | [GitHub](https://github.com/justmert/dotly) | ☐ | ☐ | ☐ |
-| [Federico Cicciarella](https://www.linkedin.com/in/federicocicciarella/?originalSubdomain=it) | [Tracking Chain](./tracking_chain.md) | [GitHub](https://github.com/TrackingChains/TrackingChain) | ☐ | ☒ | ☐ |
-| [TPScore](https://github.com/its-a-setup) | [TPScore](./TPScore.md) | [GitHub](https://github.com/its-a-setup) | ☐ | ☒ | ☐ |
-| [Orochi Network](https://www.orochi.network/) | [Research and development MPC ECDSA](./orochi-network-orosign-part1.md) | [GitHub](https://github.com/orochi-network) | ☐ | ☐ | ☐ |
+| [ChainSafe](https://chainsafe.io/) | [Polkadot Snap Maintenance](./maintenance/Substratesnap_Maintenance.md) | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☒ | ☐ |
+| [justmert](https://github.com/justmert) | [DOTLY: Revolutionizing Polkadot Account Statistics](./dotly.md) | [GitHub](https://github.com/justmert/dotly) | ☐ | ☒ | ☒ |
+| [Federico Cicciarella](https://www.linkedin.com/in/federicocicciarella/?originalSubdomain=it) | [Tracking Chain](./tracking_chain.md) | [GitHub](https://github.com/TrackingChains/TrackingChain) | ☐ | ☒ | ☒ |
+| [TPScore](https://github.com/its-a-setup) | [TPScore](./TPScore.md) | [GitHub](https://github.com/its-a-setup) | ☐ | ☒ | ☒ |
+| [Orochi Network](https://www.orochi.network/) | [Research and development MPC ECDSA](./orochi-network-orosign-part1.md) | [GitHub](https://github.com/orochi-network) | ☐ | ☒ | ☒ |
| [k/factory](https://k-f.co/) | [On-Chain Automated Treasury Management](./centrifuge-twamm.md) | [GitHub](https://github.com/centrifuge) | ☐ | ☐ | ☐ |
-| [AISLAND DAO](https://aisland.io) | [Aisland Docsig](./Aisland-DocSig.md) | [GitHub](https://github.com/aisland-dao) | ☐ | ☒ | ☐ |
-| [Eiger](https://www.eiger.co/) | [Storage solution on Polkadot](./Eiger_Storage_on_Polkadot_1.md) | [GitHub](https://github.com/eigerco) | ☐ | ☐ | ☐ |
+| [AISLAND DAO](https://aisland.io) | [Aisland Docsig](./Aisland-DocSig.md) | [GitHub](https://github.com/aisland-dao) | ☐ | ☒ | ☒ |
+| [Eiger](https://www.eiger.co/) | [Storage solution on Polkadot](./Eiger_Storage_on_Polkadot_1.md) | [GitHub](https://github.com/eigerco) | ☐ | ☒ | ☒ |
| [Salaheldin Soliman](https://github.com/salaheldinsoliman) | [Solang Playground](Solang_Playground.md) | [GitHub](https://github.com/salaheldinsoliman) | ☐ | ☐ | ☐ |
-| [P2P.ORG](http://p2p.org/) | [P2P data platform](data_platform_with_deep_indexed_data_and_staking_reports.md) | [GitHub](https://github.com/p2p-org) | ☐ | ☐ | ☐ |
+| [P2P.ORG](http://p2p.org/) | [P2P data platform](data_platform_with_deep_indexed_data_and_staking_reports.md) | [GitHub](https://github.com/p2p-org) | ☐ | ☒ | ☒ |
| [CoinFabrik](https://www.coinfabrik.com/) | [CoinFabrik On Ink Integration Tests](CoinFabrik_On_Ink_Integration_Tests.md) | [GitHub](https://github.com/CoinFabrik) | ☐ | ☒ | ☒ |
-| [Stake Plus Inc](https://stake.plus) | [Treasury Tracker](TreasuryTracker.md) | [GitHub](https://github.com/stake-plus) | ☐ | ☐ | ☐ |
+| [Stake Plus Inc](https://stake.plus) | [Treasury Tracker](TreasuryTracker.md) | [GitHub](https://github.com/stake-plus) | ☐ | ☒ | ☒ |
| [MOBR Systems](https://www.mobr.ai) | [Polkadot Analytics Platform](polkadot_analytics_platform.md) | [GitHub](https://github.com/mobr-ai) | ☐ | ☒ | ☐ |
-| [Infra3](https://network.infra-3.xyz) | [Hyperdot - Powerful data analysis and creations platform](Hyperdot.md) | [GitHub](https://github.com/Infra3-Network/hyperdot) | ☐ | ☐ | ☐ |
+| [Infra3](https://network.infra-3.xyz) | [Hyperdot - Powerful data analysis and creations platform](Hyperdot.md) | [GitHub](https://github.com/Infra3-Network/hyperdot) | ☐ | ☒ | ☒ |
| [David Semakula](https://github.com/davidsemakula) | [ink! analyzer (phase 2)](ink-analyzer-phase-2.md) | [GitHub](https://github.com/ink-analyzer) | ☐ | ☒ | ☐ |
-| [Myriad Systems LTD.](https://myriad.social/) | [Myriad Social](myriad_social.md) | [GitHub](https://github.com/myriadsocial/myriad-node) | ☐ | ☐ | ☐ |
+| [Myriad Systems LTD.](https://myriad.social/) | [Myriad Social](myriad_social.md) | [GitHub](https://github.com/myriadsocial/myriad-node) | ☐ | ☒ | ☐ |
| [Liisa](www.liisa.io) | [Polkadot NFT Portfolio Tracker](LiisaPortfolioTracker.md) | [GitHub](https://github.com/LiisaNFT) | ☐ | ☐ | ☐ |
-| [NeoPower Digital](https://neopower.digital/) | [Roloi - XCM Payment Automation](./roloi-xcm-payment-automation.md) | [GitHub](https://github.com/NeoPower-Digital) | ☐ | ☐ | ☐ |
+| [NeoPower Digital](https://neopower.digital/) | [Roloi - XCM Payment Automation](./roloi-xcm-payment-automation.md) | [GitHub](https://github.com/NeoPower-Digital) | ☐ | ☒ | ☐ |
| [Eiger](https://www.eiger.co/) | [MoveVM Substrate Pallet, part 2](./Substrate_Move_System_Pallet_2.md) | [GitHub](https://github.com/eigerco) | ☐ | ☐ | ☐ |
-| [Rust Syndicate x Decentration](https://www.decentration.org/) | [XCMSend](./xcmsend.md) | [GitHub](https://github.com/decentration) | ☐ | ☐ | ☐ |
+| [Rust Syndicate x Decentration](https://www.decentration.org/) | [XCMSend](./xcmsend.md) | [GitHub](https://github.com/decentration) | ☐ | ☒ | ☒ |
| [Off Narrative Labs](https://github.com/Off-Narrative-Labs) | [Tuxedo Parachain Support](./tuxedo_parachain.md) | [GitHub](https://github.com/Off-Narrative-Labs) | ☐ | ☐ | ☐ |
| [PolyCrypt GmbH](https://polycry.pt) | [Distributed Cryptography for Polkadot Wallets](./distributed_cryptography_for_polkadot_wallets.md) | [GitHub](https://github.com/perun-network) | ☐ | ☐ | ☐ |
-| [Open Smart Contract](https://github.com/OpenSmartContract) | [ISO20022 PoC](./ISO20022.md) | [GitHub](https://github.com/OpenSmartContract) | ☐ | ☐ | ☐ |
+| [Open Smart Contract](https://github.com/OpenSmartContract) | [ISO20022 PoC](./ISO20022.md) | [GitHub](https://github.com/OpenSmartContract) | ☐ | ☒ | ☒ |
| [DAOsign](https://daosign.org/) | [DAOsign](./DAOsign.md) | [GitHub](https://github.com/DAOsign) | ☐ | ☐ | ☐ |
| [Zondax AG](https://zondax.ch/) | [PoC Polkadot Conformance Tests](./polkadot_tests.md) | [GitHub](https://github.com/zondax) | ☐ | ☐ | ☐ |
-| [SO/DA zone](https://github.com/sodazone) | [Ocelloids XCM Transfer Monitoring Service](ocelloids_xcm_monitoring_service.md) | [GitHub](https://github.com/sodazone) | ☐ | ☐ | ☐ |
-| [Moonsong Labs](https://moonsonglabs.com/) | [StorageHub](./StorageHub.md) | [GitHub](https://github.com/Moonsong-Labs) | ☐ | ☐ | ☐ |
-| [Jonathan Brown](https://acuity.social/) | [Hybrid Explorer Phase 2](hybrid2.md) | [GitHub](https://github.com/hybrid-explorer) | ☐ | ☐ | ☐ |
+| [SO/DA zone](https://github.com/sodazone) | [Ocelloids XCM Transfer Monitoring Service](ocelloids_xcm_monitoring_service.md) | [GitHub](https://github.com/sodazone) | ☐ | ☒ | ☒ |
+| [Moonsong Labs](https://moonsonglabs.com/) | [StorageHub](./StorageHub.md) | [GitHub](https://github.com/Moonsong-Labs) | ☐ | ☒ | ☐ |
+| [Jonathan Brown](https://acuity.social/) | [Hybrid Explorer Phase 2](hybrid2.md) | [GitHub](https://github.com/hybrid-explorer) | ☐ | ☒ | ☐ |
+| [Coong Crafts](https://coongcrafts.io/) | [DelightfulDOT](delightfuldot.md) | [GitHub](https://github.com/CoongCrafts) | ☐ | ☐ | ☐ |
+| [Lastic](https://www.lastic.xyz/) | [Lastic](Lastic.md) | [GitHub](https://github.com/LasticXYZ) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 18 - Q2 2023
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------| :--------- | :------------: | :--------: |
-| [Interstellar](https://www.interstellar.gg/) | [Interstellar - Wallet Phase 2](./Interstellar-network2.md) | [GitHub](https://github.com/Interstellar-Network) | ☐ | ☐ | ☐ |
-| [Valletech AB](https://valletech.eu/) | [DINFRA](./DINFRA.md) | [GitHub](https://gitlab.com/polkawatch) | ☐ | ☒ | ☐ |
+| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------| :---------: | :------------: | :--------: |
+| [Interstellar](https://www.interstellar.gg/) | [Interstellar - Wallet Phase 2](./Interstellar-network2.md) | [GitHub](https://github.com/Interstellar-Network) | ☐ | ☒ | ☒ |
+| [Valletech AB](https://valletech.eu/) | [DINFRA](./DINFRA.md) | [GitHub](https://gitlab.com/polkawatch) | ☐ | ☒ | ☒ |
| [DAuth](https://github.com/DAuth-Network) | [DAuth](./dauth_network.md) | [GitHub](https://github.com/DAuth-Network) | ☐ | ☐ | ☐ |
-| [Galaxy.Do](https://galaxy.do) | [Galaxy: Three-dimensional Web for Polkadot Users](./galaxy.md) | [GitHub](https://github.com/7flash) | ☐ | ☒ | ☐ |
+| [Galaxy.Do](https://galaxy.do) | [Galaxy: Three-dimensional Web for Polkadot Users](./galaxy.md) | [GitHub](https://github.com/7flash) | ☐ | ☒ | ☒ |
| [Web3 Labs Ltd](https://www.web3labs.com/) | [Sirato (Epirus) Substrate Explorer - Phase III](./sirato_substrate_phase3.md) | [GitHub](https://github.com/web3labs) | ☐ | ☒ | ☒ |
| [Collective Intelligence Labs](https://collectiveintelligence.dev/)| [Omnichain Infrastructure](./CILA-omnichain-infrastructure.md) | [GitHub](https://github.com/Collective-Intelligence-Labs) | ☐ | ☒ | ☐ |
| [TradeLink](https://tradelink.pro/) | [Sandox](./sandox.md) | [GitHub](https://github.com/BEARlogin) | ☐ | ☒ | ☐ |
| [Wunderbar Network](https://wunderbar.network/) | [Vue.js + TypeScript Substrate Front-End Template](./vue-typescript-substrate-frontend-template.md) | [GitHub](https://github.com/WunderbarNetwork) | ☐ | ☐ | ☐ |
-| [Profond.ai](https://www.profond.ai/) | [Profond](./Profond.md) | [GitHub](https://github.com/emarai) | ☐ | ☐ | ☐ |
+| [Profond.ai](https://www.profond.ai/) | [Profond](./Profond.md) | [GitHub](https://github.com/emarai) | ☐ | ☒ | ☐ |
| [727.ventures](https://727.ventures) | [Patron](./patron.md) | [GitHub](https://github.com/727-Ventures) | ☐ | ☒ | ☒ |
| [Supercomputing Systems AG](https://www.scs.ch) | [SARP - A Static Analysis Tool for Runtime Pallets](./sarp-basic-functionality.md) | [GitHub](https://github.com/scs) | ☐ | ☒ | ☒ |
| [Ed Anderson](https://github.com/eca20) | [Blockchainia](./blockchainia.md) | [GitHub](https://github.com/eca20) | ☐ | ☐ | ☐ |
@@ -101,38 +144,38 @@ Besides, **there is a clear difference between an application being accepted and
| [Talentica Software](https://www.talentica.com/) | [Implementation Benchmarking Milestone 3](ink-pallet-benchmarking-phase-2.md) | [GitHub](https://github.com/Nikhil-Desai-Talentica) | ☐ | ☒ | ☒ |
| [Deep Ink Ventures GmbH](https://github.com/deep-ink-ventures) | [Stylograph](Stylograph.md) | [GitHub](https://github.com/deep-ink-ventures) | ☐ | ☒ | ☒ |
| [Zeeve](https://www.zeeve.io) | [Ink Playground IDE Improvements](ink-playground-ide-improvements.md) | [GitHub](https://github.com/Zeeve-App) | ☐ | ☐ | ☐ |
-| [Scio Labs](https://scio.xyz/) | [XCM Domain Name Service](xcm-domain-service.md) | [GitHub](https://github.com/scio-labs) | ☐ | ☒ | ☐ |
+| [Scio Labs](https://scio.xyz/) | [XCM Domain Name Service](xcm-domain-service.md) | [GitHub](https://github.com/scio-labs) | ☐ | ☒ | ☒ |
| [Gloslab](https://github.com/smiasojed) | [Contracts performance measurement tool proposal](contracts-tool.md) | [GitHub](https://github.com/smiasojed) | ☐ | ☒ | ☐ |
| [Nikita Orlov PR](https://github.com/stringnick) | [Faucet chat based bot](faucet-bot.md) | [GitHub](https://github.com/stringnick) | ☐ | ☒ | ☒ |
| [Societal Labs Ltd.](https://www.sctl.xyz/) | [Societal Saas Pricing](societal_saas_pricing.md) | [GitHub](https://github.com/sctllabs) | ☐ | ☒ | ☒ |
| [MASTER UNION LLC.](https://github.com/TheDotflow) | [Dotflow](Dotflow.md) | [GitHub](https://github.com/TheDotflow) | ☐ | ☒ | ☒ |
-| [Antier Solutions](https://www.antiersolutions.com/) | [RFP/securityMarketPlace](Security_Marketplace.md) | [GitHub](https://github.com/ParthChaudhary31) | ☐ | ☐ | ☐ |
+| [Antier Solutions](https://www.antiersolutions.com/) | [RFP/securityMarketPlace](Security_Marketplace.md) | [GitHub](https://github.com/ParthChaudhary31) | ☐ | ☒ | ☒ |
| [SO/DA zone](https://github.com/mfornos) | [Ocelloids Monitoring SDK grant application](ocelloids_monitoring_sdk.md) | [GitHub](https://github.com/mfornos) | ☐ | ☒ | ☒ |
| [Antier Solutions Pvt. Ltd.](https://github.com/kulwindersingh-ant)| [Grants webapp](Grant_management_webapp.md) | [GitHub](https://github.com/kulwindersingh-ant) | ☐ | ☒ | ☒ |
| [Zaniyar Jahany](https://github.com/Zaniyar/) | [Grantmaster](grantmaster.md) | [GitHub](https://github.com/Zaniyar/plant2earn/) | ☐ | ☐ | ☐ |
| [FiDi Tech](https://fidi.tech/) | [FiDi DotSight: Analytics Data Platform for DotSama](fidi-dotsight-analytics.md)| [GitHub](https://github.com/fidi-tech) | ☐ | ☒ | ☐ |
-| [Ideal Labs](https://www.idealabs.network/) | [Cryptex](cryptex.md)| [GitHub](https://github.com/ideal-lab5) | ☐ | ☒ | ☐ |
-| [Xcavate](https://xcavate.io/) | [Real estate centric lending and asset minting protocol](Xcavate.md)| [GitHub](https://github.com/xcavateblockchain) | ☐ | ☐ | ☐ |
+| [Ideal Labs](https://www.idealabs.network/) | [Cryptex](cryptex.md)| [GitHub](https://github.com/ideal-lab5) | ☐ | ☒ | ☒ |
+| [Xcavate](https://xcavate.io/) | [Real estate centric lending and asset minting protocol](Xcavate.md)| [GitHub](https://github.com/xcavateblockchain) | ☐ | ☒ | ☒ |
| [Syncra](https://syncra.xyz) | [No Code DAO Maker and ZK Powered Private Voting Solution](Syncra.md)| [GitHub](https://github.com/SyncraDAO) | ☐ | ☐ | ☐ |
-| [P2P.ORG](http://p2p.org/) | [Validator Monitoring Service](Validator_Monitoring_Service.md)| [GitHub](https://github.com/p2p-org/polkadot_monitoring_service) | ☐ | ☐ | ☐ |
+| [P2P.ORG](http://p2p.org/) | [Validator Monitoring Service](Validator_Monitoring_Service.md)| [GitHub](https://github.com/p2p-org/polkadot_monitoring_service) | ☐ | ☒ | ☒ |
| [Colorful Notion](https://github.com/colorfulnotion) | [Deep Account Analytics in Three Tiers for the Polkadot Data Alliance](DeepAccountAnalytics-PolkadotDataAlliance.md)| [GitHub](https://github.com/colorfulnotion/) | ☐ | ☐ | ☐ |
| [Dastanbek Samatov](https://dastansam.github.io/) | [ISO-8553 PoC implementation](ISO-8583-implementation.md)| [GitHub](https://github.com/dastanbeksamatov) | ☐ | ☒ | ☐ |
| [Eiger](https://www.eiger.co/) | [Substrate Move System Pallet, pt. 1](Substrate_Move_System_Pallet_1.md)| [GitHub](https://github.com/eigerco) | ☐ | ☒ | ☒ |
| [Davanti](https://github.com/liangjh) | [Dot-ETL Project](dot_etl.md)| [GitHub](https://github.com/liangjh) | ☐ | ☐ | ☐ |
| [ParaSpell](https://github.com/paraspell) | [LightSpell: XCM API](LightSpell-proposal.md)| [GitHub](https://github.com/paraspell) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 17 - Q1 2023
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------------------------------- | :--------- | :------------: | :--------: |
+| :------------------------------------------------------------------| :------------------------------------------------------------------------------------------------------| :------------------------------------------------------------------- | :---------: | :------------: | :--------: |
| [Deep Ink Ventures GmbH](http://deep-ink.ventures/) | [GenesisDAO](GenesisDAO.md) | [GitHub](https://github.com/deep-ink-ventures) | ☐ | ☒ | ☒ |
-| [ArtZero](https://artzero.io/) | [ArtZero & InkWhale](ArtZero_InkWhale.md) | [GitHub](https://github.com/artzero-io) | ☐ | ☒ | ☐ |
+| [ArtZero](https://artzero.io/) | [ArtZero & InkWhale](ArtZero_InkWhale.md) | [GitHub](https://github.com/artzero-io) | ☐ | ☒ | ☒ |
| [EightFish](https://github.com/eightfish-org/eightfish) | [EightFish](eightfish.md) | [GitHub](https://github.com/miketang84/eightfish) | ☐ | ☒ | ☒ |
| [Protofire](https://protofire.io/) | [Polkadot Contract Wizard](polkadot-contract-wizard.md) | [GitHub](https://github.com/protofire/) | ☐ | ☒ | ☒ |
-| [Runtime Verification](https://runtimeverification.com/) | [KMIR: the K semantics of MIR](rv-kmir.md) | [GitHub](https://github.com/runtimeverification) | ☐ | ☒ | ☐ |
-| [Me Protocol](https://meprotocol.io/) | [Me Protocol](MeProtocol.md) | [GitHub](https://github.com/Me-Protocol) | ☐ | ☐ | ☐ |
+| [Runtime Verification](https://runtimeverification.com/) | [KMIR: the K semantics of MIR](rv-kmir.md) | [GitHub](https://github.com/runtimeverification) | ☐ | ☒ | ☒ |
+| [Me Protocol](https://meprotocol.io/) | [Me Protocol](MeProtocol.md) | [GitHub](https://github.com/Me-Protocol) | ☐ | ☒ | ☐ |
| [Comrade Coop](https://comrade.coop/) | [Validated Streams](validated-streams.md) | [GitHub](https://github.com/comrade-coop) | ☐ | ☒ | ☒ |
| [Blockcoders](http://blockcoders.io/) | [Kuma Cross-chain Wallet](cross-chain-wallet.md) | [GitHub](https://github.com/blockcoders) | ☐ | ☒ | ☒ |
| [OmniBTC](https://omnibtc.finance/) | [Polkadot Smart Chain](psc.md) | [GitHub](https://github.com/OmniBTC/PSC) | ☐ | ☒ | ☒ |
@@ -148,7 +191,7 @@ Besides, **there is a clear difference between an application being accepted and
| [CoinFabrik](https://www.coinfabrik.com/) | [Scout - Security Analysis Tool](ScoutCoinFabrik.md) | [GitHub](https://github.com/coinfabrik) | ☐ | ☒ | ☒ |
| [727.ventures](https://727.ventures/) | [Typechain-Polkadot Follow-up-2](typechain-polkadot-follow-up-2.md) | [GitHub](https://github.com/727-Ventures/typechain-polkadot) | ☐ | ☒ | ☒ |
| [Mark Van de Vyver PhD(Dist)](https://www.student.uwa.edu.au/course/award-verification-service?family=van+de+vyver&family_partial=on&given=mark&search=Search) | [Substrate Tokenomics Survey](tokenomics-survey-2022.md) | [GitHub](https://github.com/taqtiqa-mark) | ☐ | ☒ | ☐ |
-| [Zeeve](https://www.zeeve.io) | [Parachain deployment zoombienet testing automation](Zeeve_Parachain_deployment_zoombienet_testing_automation.md) | [GitHub](https://github.com/Zeeve-App) | ☐ | ☒ | ☐ |
+| [Zeeve](https://www.zeeve.io) | [Parachain deployment zoombienet testing automation](Zeeve_Parachain_deployment_zoombienet_testing_automation.md) | [GitHub](https://github.com/Zeeve-App) | ☐ | ☒ | ☒ |
| [Polytope Labs](https://research.polytope.technology/) | [Trie Verifier Implementation](solidity-trie-verifier.md) | [GitHub](https://github.com/polytope-labs) | ☐ | ☒ | ☒ |
| [Off-Narrative Labs](https://github.com/Off-Narrative-Labs) | [Tuxedo](tuxedo.md) | [GitHub](https://github.com/JoshOrndorff) | ☐ | ☒ | ☒ |
| [FuzzLand](https://fuzz.land/) | [FuzzLand](FuzzLand.md) | [GitHub](https://github.com/fuzzland) | ☐ | ☐ | ☐ |
@@ -162,26 +205,26 @@ Besides, **there is a clear difference between an application being accepted and
| [ParaSpell](https://github.com/paraspell) | [ParaSpell_Follow Up 2](ParaSpell_follow-up2.md) | [GitHub](https://github.com/paraspell) | ☐ | ☒ | ☒ |
| [justmert](https://github.com/justmert) | [PolkaFlow](polkaflow.md) | [GitHub](https://github.com/justmert) | ☐ | ☒ | ☒ |
| [BelSoft](https://www.belsoft.rs) | [Diffy messenger](Diffy_chat.md) | [GitHub](https://github.com/1db1) | ☐ | ☒ | ☒ |
-| [Zkverse](https://github.com/Zkvers) | [Zkverse](zkverse.md) | [GitHub](https://github.com/Zkvers/substrate-zk) | ☐ | ☐ | ☐ |
+| [Zkverse](https://github.com/Zkvers) | [Zkverse](zkverse.md) | [GitHub](https://github.com/Zkvers/substrate-zk) | ☐ | ☒ | ☐ |
| [Taiwan Research-based Biopharmaceutical Manufacturers Association](https://trpma.org.tw/cmn) | [Claps Health](Claps.md) | [GitHub](https://github.com/Claps-Health/) | ☐ | ☐ | ☐ |
| [Tolga Yaycı](https://github.com/tolgayayci) | [Awesome Polka](Awesome-Polka.md) | [GitHub](https://github.com/tolgayayci/awesome-polka/tree/dev) | ☐ | ☒ | ☒ |
-| [gmajor](https://github.com/gmajor-encrypt) | [XCM Tools](xcm-tools.md) | [GitHub](https://github.com/gmajor-encrypt/) | ☐ | ☒ | ☐ |
+| [gmajor](https://github.com/gmajor-encrypt) | [XCM Tools](xcm-tools.md) | [GitHub](https://github.com/gmajor-encrypt/) | ☐ | ☒ | ☒ |
| [David Semakula](https://github.com/davidsemakula) | [ink! Analyzer](ink-analyzer.md) | [GitHub](https://github.com/ink-analyzer) | ☐ | ☒ | ☒ |
| [Bright Inventions](https://brightinventions.pl/) | [High-availability validator setup](High_availability_validator_setup.md) | [GitHub](https://github.com/bright/) | ☐ | ☒ | ☒ |
| [DIA Data](https://www.diadata.org/) | [Bridgestate Attestation Oracle](DIA_Bridge_Attestation_Oracle.md) | [GitHub](https://github.com/diadata-org/) | ☐ | ☒ | ☒ |
| [TogetherCrew](http://www.togethercrew.com/) | [Community Health Check](community-health-check.md) | [GitHub](https://github.com/RnDAO) | ☐ | ☒ | ☐ |
| [Decentration](https://www.decentration.org/) | [Supersig Phase 2](./supersig_fellowship.md) | [GitHub](https://github.com/decentration) | ☐ | ☒ | ☒ |
| [Polkadrys Labs](https://github.com/rtomas) | [Open Payroll](./openPayroll.md) | [GitHub](https://github.com/rtomas) | ☐ | ☒ | ☐ |
-| [Itering](https://www.itering.io/) | [Solidity Verifier Implementation for Accountable Light Client](./solidity-verifier-for-accountable-light-client.md) | [GitHub](https://github.com/darwinia-network) | ☐ | ☒ | ☐ |
+| [Itering](https://www.itering.io/) | [Solidity Verifier Implementation for Accountable Light Client](./solidity-verifier-for-accountable-light-client.md) | [GitHub](https://github.com/darwinia-network) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
## 2022
### 🏄 Wave 16 - Q4 2022
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :----------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :----------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [CrossChain Labs](https://github.com/CrossChainLabs) | [DotPulse](DotPulse.md) | [GitHub](https://github.com/CrossChainLabs) | ☐ | ☒ | ☒ |
| [Jett Hays](https://github.com/jettblu) | [Distributed Key Management](DistributedKeyManagement.md) | [GitHub](https://github.com/KryptikApp) | ☐ | ☒ | ☒ |
| [NexToken Technology](https://github.com/NexTokenTech) | [TREX - Timed Release Encryption Xing chains](TREX_Network.md) | [GitHub](https://github.com/NexTokenTech/TREX) | ☐ | ☒ | ☒ |
@@ -201,14 +244,14 @@ Besides, **there is a clear difference between an application being accepted and
| [10Clouds Sp. z o.o.](https://10clouds.com/) | [Crowdloan Front End Template](crowdloan_frontend_template.md) | [GitHub](https://github.com/10clouds) | ☐ | ☒ | ☒ |
| [DodoRare, Inc.](https://dodorare.com/) | [Faterium](faterium.md) | [GitHub](https://github.com/faterium) | ☐ | ☒ | ☒ |
| [The Bacon Beacon](https://github.com/random-bacon) | [Pallet Drand Client](pallet-drand-client.md) | [GitHub](https://github.com/random-bacon) | ☐ | ☒ | ☐ |
-| [Helikon Labs](https://helikon.io/) | [ChainViz v1](chainviz.md) | [GitHub](https://github.com/helikon-labs/chainviz) | ☐ | ☐ | ☐ |
+| [Helikon Labs](https://helikon.io/) | [ChainViz v1](chainviz.md) | [GitHub](https://github.com/helikon-labs/chainviz) | ☐ | ☒ | ☐ |
| [Mutai Solutions](https://bryanmutai.co/) | [Crowdloans-FET](Crowdloans-FET.md) | [GitHub](https://github.com/brymut) | ☐ | ☐ | ☐ |
| [k/factory](https://k-f.co/) | [Centrifuge Go-Substrate-RPC Client V2](centrifuge-gsrpc-v2.md) | [GitHub](https://github.com/centrifuge/go-substrate-rpc-client) | ☐ | ☐ | ☐ |
| [Colorful Notion](https://github.com/colorfulnotion) | [Zombienet Explorer: Multi-Chain Substrate Block Explorer](Zombienet-Explorer.md) | [GitHub](https://github.com/colorfulnotion/zombienet-explorer) | ☐ | ☐ | ☐ |
| [TwinP](https://github.com/herou) | [Decentralized Invoice](decentralized_invoice.md) | [GitHub](https://github.com/herou) | ☐ | ☒ | ☒ |
| [Zondax](http://zondax.ch/) | [Hybrid node research grant](hybrid_node_research.md) | [GitHub](https://github.com/ZondaX) | ☐ | ☒ | ☒ |
| [Bright Inventions](https://brightinventions.pl/) | [ZK-Snarks Tutorial](ZK-Snarks%20tutorial.md) | [GitHub](https://github.com/bright/) | ☐ | ☒ | ☒ |
-| [Common Orbit LLC](https://brson.github.io) | [wasm-opt-for-rust maintenance](maintenance/wasm-opt-for-rust.md) | [GitHub](https://github.com/brson/wasm-opt-rs) | ☐ | ☒ | ☐ |
+| [Common Orbit LLC](https://brson.github.io) | [wasm-opt-for-rust maintenance](maintenance/wasm-opt-for-rust.md) | [GitHub](https://github.com/brson/wasm-opt-rs) | ☐ | ☒ | ☒ |
| [Salaheldin Soliman](https://github.com/salaheldinsoliman) | [Solang developer experience improvements](Solang_developer_experience_improvements.md) | [GitHub](https://github.com/hyperledger/solang) | ☐ | ☒ | ☒ |
| [Optymalizacja AI Grzegorz Miebs](https://github.com/miepsik) | [Validator selection](validators_selection.md) | [GitHub](https://github.com/miepsik) | ☐ | ☒ | ☒ |
| [Applied Blockchain Ltd](https://appliedblockchain.com/) | [Silent Data](project_silentdata.md) | [GitHub](https://github.com/appliedblockchain) | ☐ | ☒ | ☒ |
@@ -222,12 +265,12 @@ Besides, **there is a clear difference between an application being accepted and
| [Aband-Network](https://a.band/) | [Substrate Parachain PoS Template](substrate-parachain-PoS-template.md) | [GitHub](https://github.com/Aband-Network/substrate-parachain-PoS-template) | ☐ | ☒ | ☒ |
| [MangoBOX labs](https://www.mangobox.xyz/) | [MangoSale Protocol](MangoSale_Protocol.md) | [GitHub](https://github.com/Mangoboxlabs) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 15 - Q3 2022
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :----------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :----------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [QRUCIAL OÜ](https://qrucial.io/) | [QRUCIAL DAO](./QRUCIAL_DAO.md) | [GitHub](https://github.com/Qrucial/QRUCIAL-DAO) | ☐ | ☒ | ☒ |
| [Polkadot js plus](http://polkadotjs.plus/) | [Polkadot js plus / Social Recovery Wallet](./Plus-social-recovery-wallet.md) | [GitHub](https://github.com/Nick-1979/polkadot-Js-Plus-extension/wiki) | ☐ | ☒ | ☐ |
| [Lee](https://github.com/rust-0x0) | [Hex Space Social Graph](./hex.md) | [GitHub](https://github.com/rust-0x0) | ☐ | ☒ | ☐ |
@@ -268,15 +311,15 @@ Besides, **there is a clear difference between an application being accepted and
| [Standard Protocol](https://standard.tech/) | [New Order - a full onchain orderbook dex with indexers](./Standard_Protocol.md) | [GitHub](https://github.com/standardweb3) | ☒ | ☐ | ☐ |
| [hack-ink](https://github.com/hack-ink) | [Subalfred](./subalfred.md) | [GitHub](https://github.com/hack-ink/subalfred) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 14 - Q2 2022
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :--------------------------------------------------------- | :------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :--------------------------------------------------------- | :------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [TDSoftware](https://www.tdsoftware.de/) | [SubIdentity](./SubIdentity.md) | [GitHub](https://github.com/TDSoftware) | ☐ | ☒ | ☒ |
| [ChainSafe Systems](https://chainsafe.io/) | [SubstrateSnap Maintenance Proposal](./maintenance/Substratesnap_Maintenance.md) | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☒ | ☒ |
-| [HugoByte](https://hugobyte.com/) | [Project Aurras - MVP - Phase 2](./project_aurras_mvp_phase_2.md) | [GitHub](https://github.com/HugoByte) | ☐ | ☒ | ☐ |
+| [HugoByte](https://hugobyte.com/) | [Project Aurras - MVP - Phase 2](./project_aurras_mvp_phase_2.md) | [GitHub](https://github.com/HugoByte) | ☐ | ☒ | ☒ |
| [Perun Network](https://perun.network/) | [Perun App Channels](./perun_app_channels.md) | [GitHub](https://github.com/perun-network/) | ☐ | ☒ | ☒ |
| [ChainSafe Systems](https://chainsafe.io/) | [Privacy enhancement for Polkadot-js extension](./polkadot-js-extension-per-account-auth.md) | [GitHub](https://github.com/ChainSafe) | ☐ | ☒ | ☒ |
| [BQP](https://qbitcoin.tech/) | [Quantum Lock for QBITCOIN](./quantumLock.md) | [GitHub](https://github.com/bqpquantum/) | ☐ | ☐ | ☐ |
@@ -311,12 +354,12 @@ Besides, **there is a clear difference between an application being accepted and
| [Hypha Hashed Partners](https://hypha.earth/) | [Social Recovery Wallet](./social_recovery_wallet.md) | [GitHub](https://github.com/hypha-dao) | ☐ | ☒ | ☒ |
| [MangoBOX labs](http://mangobox.xyz/) | [MangoBOX Protocol](./MangoBOX-Protocol.md) | [GitHub](https://github.com/Mangoboxlabs) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 13 - Q1 2022
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :---------------------------------------------------- | :-------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :---------------------------------------------------- | :-------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [Chainify](https://github.com/chainify) | [Nolik](./Nolik.md) | [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](./anagolay-project-idiyanale-phase-1.md) | [GitHub](https://github.com/anagolay) | ☐ | ☒ | ☒ |
@@ -350,14 +393,12 @@ Besides, **there is a clear difference between an application being accepted and
| [NUTS Finance](https://nuts.finance) | [DOT-pegged derivative built on top of the stable asset protocol](./tdot.md) | [GitHub](https://github.com/nutsfinance/) | ☒ | ☒ | ☐ |
| [Strategy Object](https://strategyobject.com/) | [Substrate Client for Java](./substrate_client_java.md) | [GitHub](https://github.com/strategyobject/substrate-client-java) | ☐ | ☒ | ☐ |
-[🔝](#2023)
+[🔝](#top)
## 2021
-
### 🏄 Wave 12 - Q4 2021
-
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :--------------------------------------------------------- | :---------------------------------------------------------------------------------------- | :------------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :--------------------------------------------------------- | :---------------------------------------------------------------------------------------- | :------------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| Matthew Darnell | [cScale](./cScale.md) | [GitHub](https://github.com/MatthewDarnell/cScale) | ☐ | ☒ | ☐ |
| [Web3go](https://web3go.xyz/) | [Web3go](./Web3Go.md) | [GitHub](https://github.com/web3go-xyz) | ☐ | ☒ | ☒ |
| [Prosopo Limited](https://prosopo.io) | [Prosopo: Human Verification Marketplace](./prosopo.md) | [GitHub](https://github.com/prosopo-io) | ☐ | ☒ | ☒ |
@@ -376,16 +417,19 @@ Besides, **there is a clear difference between an application being accepted and
| [Elamin LTD](http://imbue.network/) | [Imbue Network](./imbue_network.md) | [GitHub](https://github.com/ImbueNetwork) | ☐ | ☒ | ☒ |
| [Koi Metaverse](https://koi.io/) | [Building the Digital Collectibles Platform for Virtual GameFi NFTs](./Koiverse.md) | [GitHub](https://github.com/KoiMetaverse) | ☐ | ☐ | ☐ |
| [Health Hero](https://www.gohealthhero.com/) | [Decentralized Well-being Game API](./decentralized_well-being_game_api.md) | [GitHub](https://github.com/iumairazhar) | ☐ | ☐ | ☐ |
-| [UNIVERSALDOT FOUNDATION](https://universaldot.foundation) | [A freelancing decentralized application](./universaldot.me.md) | [GitHub](https://github.com/UniversalDot) | ☐ | ☒ | ☒ |
+| [UNIVERSALDOT FOUNDATION](https://universaldot.foundation) | [A freelancing decentralized application](./universaldot.me.md) | [GitHub](https://github.com/UniversalDot) | ☒ | ☒ | ☐ |
| [AdMeta](https://admeta.network/) | [A privacy-preserving Ad Platform](./AdMeta.md) | [GitHub](https://github.com/AdMetaNetwork/admeta) | ☐ | ☒ | ☒ |
-| Crypto Pay Lab (CPL)) | [Dotpay a github paid task platform using DOT](./DotPay.md) | [GitHub](https://github.com/bytepayment) | ☐ | ☒ | ☐ |
+| Crypto Pay Lab (CPL)) | [Dotpay a github paid task platform using DOT](./DotPay.md) | [GitHub](https://github.com/bytepayment) | ☐ | ☒ | ☒ |
+
+
+
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 11 - Q3 2021
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :---------------------------------------------- | :---------------------------------------------------------------------------------------- | :-------------------------------------------------- | :--------- | :------------: | :-------: |
+| :---------------------------------------------- | :---------------------------------------------------------------------------------------- | :-------------------------------------------------- | :---------: | :------------: | :-------: |
| [Pawn](https://github.com/pawnz0) | [NuLink](./NuLink.md) | [GitHub](https://github.com/pawnz0/NuLink) | ☐ | ☒ | ☒ |
| [Cyril Carlier](https://github.com/CrommVardek) | [Polk-Auction Website](./polk-auction.md) | [GitHub](https://github.com/CrommVardek) | ☐ | ☒ | ☒ |
| [Uddug](https://uddug.com/) | [JuniDB - Peer-to-Peer Databases](./JuniDB.md) | [GitHub](http://github.com/uddugteam/) | ☒ | ☐ | ☐ |
@@ -399,7 +443,7 @@ Besides, **there is a clear difference between an application being accepted and
| [Valibre](https://valibre.org) | [People Local Interactions Protocol (PLIP)](./plip.md) | [GitHub](https://github.com/valibre-org/) | ☐ | ☐ | ☐ |
| [Reaudito](https://shivarthu.reaudito.com/#/) | [Shivarthu: A blockchain-based decentralized governance system](./Shivarthu.md) | [GitHub](https://github.com/amiyatulu/shivarthu) | ☐ | ☒ | ☐ |
| Uniscan | [NFT Explorer](./nft_explorer.md) | [GitHub](https://github.com/wuminzhe) | ☐ | ☒ | ☒ |
-| [LimeChain](https://limechain.tech) | [Subsembly - Support for GRANDPA](./assemblyscript-scale-codec.md) | [GitHub](https://github.com/LimeChain) | ☐ | ☐ | ☐ |
+| [LimeChain](https://limechain.tech) | [Subsembly - Support for GRANDPA](./assemblyscript-scale-codec.md) | [GitHub](https://github.com/LimeChain) | ☐ | ☒ | ☒ |
| [OpenSquare](https://www.opensquare.network) | [Off-chain voting platform](./OpenSquare_paid_qa_protocol.md) | [GitHub](https://github.com/opensquare-network/) | ☐ | ☒ | ☒ |
| [Health Hero](https://www.gohealthhero.com/) | [NFT Product Analytics Suite](./nft_product_analytics_suite.md) | | ☐ | ☐ | ☐ |
| [Tesseract](https://tesseract.one/) | Mobile dApps/Wallet Connection | [GitHub](https://github.com/tesseract-one) | ☐ | ☒ | ☒ |
@@ -413,12 +457,12 @@ Besides, **there is a clear difference between an application being accepted and
| [Skye Kiwi](https://skye.kiwi/) | [SkyeKiwi Protocol](./skyekiwi-protocol.md) | [GitHub](https://github.com/skyekiwi) | ☐ | ☒ | ☒ |
| [Evercity](https://evercity.io/) | Sustainable Finance Protocol | [GitHub](https://github.com/EvercityEcosystem) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 10 - Q2 2021
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :----------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :----------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [GamePower](https://gamepower.network) | [NFT Collectibles Wallet](./nft_collectibles_wallet.md) | [GitHub](https://github.com/GamePowerNetwork) | ☐ | ☒ | ☐ |
| [Subspace Labs](https://www.subspace.network/) | [Proof-of-Capacity Consensus for Substrate](./spartan_poc_consensus_module.md) | [GitHub](https://github.com/subspace) | ☐ | ☒ | ☒ |
| [ChainSafe](https://chainsafe.io/) | Go implementation of Cumulus | [GitHub](https://github.com/ChainSafeSystems) | ☐ | ☐ | ☐ |
@@ -430,14 +474,14 @@ Besides, **there is a clear difference between an application being accepted and
| [element36](https://element36.io) | [FIAT on-off-ramp](./FIAT-on-off-ramp.md) | [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](./parachain-staking.md) | [GitHub](https://github.com/PureStake/moonbeam) | ☐ | ☒ | ☒ |
-| [Dora Factory](https://dorafactory.org/) | [MolochDAO substrate pallets v1 and v2](./dora-factory-molochdao-v1-v2.md) | [GitHub](https://github.com/DoraFactory) | ☐ | ☒ | ☐ |
+| [Dora Factory](https://dorafactory.org/) | [MolochDAO substrate pallets v1 and v2](./dora-factory-molochdao-v1-v2.md) | [GitHub](https://github.com/DoraFactory) | ☐ | ☒ | ☒ |
| BCANN | [Blockchain system for Assigned Names And Numbers](./BCANN.md) | [GitHub](https://github.com/weitaolee) | ☐ | ☐ | ☐ |
| [MyBank Labs](https://mybank.network/) | [Platform Bank, Social Network Bank, MyDeX and Credit Scoring System](./mybank.md) | [GitHub](https://github.com/mybank-network/mybank-network) | ☐ | ☐ | ☐ |
| [ChainBridge Network](https://github.com/ChainBridgeNetworkTeam) | [Doter: A browser extension wallet for Polkadot](./Doter.md) | [GitHub](https://github.com/ChainBridgeNetworkTeam) | ☐ | ☒ | ☒ |
| [SubDAO Labs](https://www.subdao.network/) | [SubDAO Chrome Extension](./SubDAO-Chrome-Extension.md) | [GitHub](https://github.com/subdao-network) | ☐ | ☒ | ☒ |
| [Sukhavati Labs](https://sukhavati.io/) | [Sukhavati PoC Module](./sukhavati_poc_module.md) | [GitHub](https://github.com/Sukhavati-Labs) | ☐ | ☐ | ☐ |
| [HypeLabs Inc.](https://hypelabs.io) | [UpLink - Decentralized and infrastructure-free approach to peer-to-peer connectivity](./uplink.md) | [GitHub](https://github.com/Hype-Labs) | ☐ | ☐ | ☐ |
-| Jackson Harris III | [Staking Rewards Viewer](./staking-rewards-collector-front-end.md) | [GitHub](https://github.com/jackson-harris-iii/staking-rewards-viewer) | ☐ | ☐ | ☐ |
+| Jackson Harris III | [Staking Rewards Viewer](./staking-rewards-collector-front-end.md) | [GitHub](https://github.com/jackson-harris-iii/staking-rewards-viewer) | ☐ | ☒ | ☒ |
| [Klevoya](https://klevoya.com/) | [WASM Smart Contract Fuzzer](./klevoya_fuzzer.md) | [GitHub](https://github.com/klevoya/) | ☐ | ☐ | ☐ |
| [Perun Network](https://perun.network/) | [Perun Channels](./perun_channels.md) | [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)](./newomega-m3m4.md) | [GitHub](https://github.com/WiktorStarczewski/newomega.trinity ) | ☐ | ☒ | ☒ |
@@ -449,20 +493,20 @@ Besides, **there is a clear difference between an application being accepted and
| [CryptoLab](https://www.cryptolab.network) | [Staking Reward Collector](./cryptolab-staking-reward-collector-front-end.md) | [GitHub](https://github.com/cryptolab-network) | ☐ | ☒ | ☒ |
| [Yatima Inc](https://github.com/yatima-inc/yatima) | [Lambda-VM and programming language for Substrate](./yatima.md) | [GitHub](https://github.com/yatima-inc/yatima) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 9 - Q1 2021
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :---------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :---------------------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [Zenlink](https://zenlink.pro/) | [Cross-chain DEX](./zenlink.md) | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) | ☐ | ☐ | ☐ |
| [NFTT Studio](https://github.com/NFTT-studio) | [NFT Store Pallet and Front End](./NFTStore_Network.md) | [GitHub](https://github.com/NFTT-studio) | ☐ | ☒ | ☒ |
| [SubGame Network](https://subgame.org) | [A decentralized game platform](./SubGame_Network.md) | [GitHub](https://github.com/SubGame-Network) | ☐ | ☒ | ☒ |
| [Parami](https://parami.io) | [Blockchain-empowered advertising alliance](./parami-protocol.md) | [GitHub](https://github.com/parami-protocol/parami) | ☐ | ☐ | ☐ |
| [Sunrise Protocol](https://sunriseprotocol.com) | [Sunrise DEX](./sunrise-dex.md) | [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](./SubsCrypt.md) | [GitHub](https://github.com/oxydev) | ☐ | ☒ | ☐ |
-| [DNFT-Team](https://github.com/DNFT-Team) | [Data framework between personal data and AI models](./DNFT.md) | [GitHub](https://github.com/DNFT-Team) | ☒ | ☐ | ☐ |
+| [OxyDev](https://oxydev.ir) | [SubsCrypt: Managing subscriptions](./SubsCrypt.md) | [GitHub](https://github.com/oxydev) | ☐ | ☒ | ☒ |
+| [DNFT-Team](https://github.com/DNFT-Team) | [Data framework between personal data and AI models](./DNFT.md) | [GitHub](https://github.com/DNFT-Team) | ☐ | ☐ | ☐ |
| [UMC Labs](https://umc.network) | [Secured token subscription](./UMC-Tokenscribe.md) | [GitHub](https://github.com/umc-network) | ☐ | ☐ | ☐ |
| [Perpetual Altruism Ltd](https://cryptograph.co/) | [IP-Rights compliant NFT bridge protocol](./NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md) | [GitHub](https://github.com/Perpetual-Altruism-Ltd) | ☐ | ☐ | ☐ |
| [Clover](https://clover.finance/) | [Easy-to-use blockchain infrastructure](./clover_network.md) | [GitHub](https://github.com/clover-network/) | ☒ | ☒ | ☐ |
@@ -470,10 +514,10 @@ Besides, **there is a clear difference between an application being accepted and
| [SEOR](https://www.seor.io) | [Multi-chain smart contract development platform](./SEOR-code-less-smart-contract-platform.md) | [GitHub](https://github.com/SealSC) | ☐ | ☒ | ☐ |
| [Polkastarter](https://polkastarter.com/) | [Crowdloan UI](./polkastarter.md) | [GitHub](https://github.com/polkastarter) | ☒ | ☐ | ☐ |
| [Equilibrium.io](https://equilibrium.io/en) | [Curve AMM Pallet](./curve_amm.md) | [GitHub](https://github.com/equilibrium-eosdt) | ☐ | ☒ | ☒ |
-| [Zondax](https://zondax.ch/) | [Ledger maintenance + recovery extensions + support](./Zondax-Support.md) | [GitHub](https://github.com/Zondax) | ☐ | ☒ | ☒ |
+| [Zondax](https://zondax.ch/) | [Ledger maintenance + recovery extensions + support](./maintenance/Zondax-Support.md) | [GitHub](https://github.com/Zondax) | ☐ | ☒ | ☒ |
| [Nuclei Studio](https://nuclei.studio/) | [Voting Pallets](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/nuclei_governance_os_voting.md) | [GitHub](https://github.com/NucleiStudio) | ☐ | ☒ | ☒ |
| [RAMP DEFI](https://app.rampdefi.com/#/) | [Polkakeeper - A Community-Led Value Assurance Protocol](./polkakeeper.md) | [GitHub](https://github.com/RAMP-DEFI) | ☐ | ☐ | ☐ |
-| [Stone](https://stonedefi.io) | [Index project which aims to track the portfolio of multiple digital assets](./stone-index-on-substrate.md) | [GitHub](https://github.com/stonedefi/) | ☐ | ☒ | ☐ |
+| [Stone](https://stonedefi.io) | [Index project which aims to track the portfolio of multiple digital assets](./stone-index-on-substrate.md) | [GitHub](https://github.com/stonedefi/) | ☐ | ☒ | ☒ |
| [Reserve Labs](https://github.com/ReserveLabs) | [AlgoCash - An algorithmic stablecoin](./AlgoCash.md) | [GitHub](https://github.com/ReserveLabs/AlgoCash) | ☐ | ☒ | ☒ |
| [gmajor](https://github.com/gmajor-encrypt) | [PHP Scale Codec](./php-scale-lib.md) | [GitHub](https://github.com/gmajor-encrypt/php-scale-codec) | ☐ | ☒ | ☒ |
| [Trust Fractal GmbH](https://trustfractal.com/) | [ink! Smart Contract Upgradeability](./upgradeability-by-proxy.md) | [GitHub](https://github.com/trustfractal/ink-upgrade-template) | ☐ | ☒ | ☒ |
@@ -485,7 +529,7 @@ Besides, **there is a clear difference between an application being accepted and
| [Standard protocol](https://github.com/standardweb3/standard-substrate) | [A collateralized algorithmic stablecoin protocol for synthetic assets](./Standard_Protocol.md) | [GitHub](https://github.com/standardweb3/standard-substrate) | ☐ | ☒ | ☐ |
| [Skye Kiwi](https://skye.kiwi/) | [SkyePass: A decentralized, open source password manager](./skyepass.md) | [GitHub](https://github.com/skyekiwi) | ☐ | ☒ | ☐ |
| [RidOne Technologies](https://github.com/RidOne-technologies) | [Polkadot UI Web + Angular Identicon](./Polkadot_Web_UI.md) | [GitHub](https://github.com/RidOne-technologies) | ☐ | ☒ | ☒ |
-| [Zeropool](https://zeropool.network/) | [Private transactions on Polkadot Phase 2](./ZeroPool.md) | [GitHub](https://github.com/zeropoolnetwork) | ☐ | ☐ | ☐ |
+| [Zeropool](https://zeropool.network/) | [Private transactions on Polkadot Phase 2](./ZeroPool.md) | [GitHub](https://github.com/zeropoolnetwork) | ☐ | ☒ | ☒ |
| [OAK Foundation](https://oak.tech) | [Quadratic Funding Module and Dapp Application](./quadratic-funding.md) | [GitHub](https://github.com/OAK-Foundation/) | ☐ | ☒ | ☒ |
| [Commonwealth Labs](https://commonwealth.im/) | [Webb Mixer](./MIXER.md) | [GitHub](https://github.com/edgeware-builders) | ☐ | ☒ | ☒ |
| [TEA Project](http://teaproject.org/) | [Gluon - Decentralized Hardware Crypto Wallet Services](./Gluon_decentralized_hardware_crypto_wallet_services.md) | [GitHub](https://github.com/tearust) | ☐ | ☒ | ☐ |
@@ -504,14 +548,14 @@ Besides, **there is a clear difference between an application being accepted and
| [Vera](https://veraprotocol.org/) | [NFT Lending + Exchange](./vera_defi.md) | [GitHub](https://github.com/veraprotocol) | ☐ | ☒ | ☒ |
| [Parallel Finance](https://parallel.fi/#/) | [Decentralized lending/borrowing and staking protocol](./Parallel.md) | [GitHub](https://github.com/parallel-finance/parallel) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
## 2020
### 🏄 Wave 8 - Q4 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) | ☐ | ☒ | ☒ |
| [Nuclei Studio](https://nuclei.studio/) | [Governance OS](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/nuclei_governance_os.md) | [GitHub](https://github.com/NucleiStudio) | ☐ | ☒ | ☒ |
| [NBLTrust](https://www.nbltrust.com/#/en/home) | [Dart SCALE Codec](./dart-scale-codec.md) | [GitHub](https://github.com/nbltrust/dart-scale-codec) | ☐ | ☒ | ☒ |
@@ -556,12 +600,12 @@ Besides, **there is a clear difference between an application being accepted and
| [HugoByte](https://hugobyte.com/) | [Project Aurras: Event Manager](./project_aurras_mvp_phase_1.md) | [GitHub](https://github.com/HugoByte) | ☐ | ☒ | ☒ |
| [Bounce Protocol](https://bounce.finance/) | [Decentralized Auction Protocol](./bounce-protocol.md) | [GitHub](https://github.com/bouncefinance/bounce-network) | ☐ | ☐ | ☐ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 7 - Q3 2020
| 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](./halva_framework.md) | [GitHub](https://github.com/halva-suite) | ☐ | ☒ | ☒ |
| [Subscan](https://subscan.io) | [Substrate explorer](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/subscan_grant_application.md) | [GitHub](https://github.com/subscan-explorer/subscan-essentials) | ☐ | ☒ | ☒ |
| [t3rn](https://github.com/t3rn/t3rn) | [A protocol for blockchain interoperability](./xbi-format-psp-t3rn.md) | [GitHub](https://github.com/t3rn/t3rn) | ☐ | ☒ | ☒ |
@@ -587,19 +631,19 @@ Besides, **there is a clear difference between an application being accepted and
| [SubDEX](http://subdex.io.s3.eu-west-2.amazonaws.com/index.html) | [A decentralized cross-chain exchange based on AMM](./subdex.md) | [GitHub](https://github.com/subdarkdex) | ☐ | ☒ | ☒ |
| [Zenlink](https://zenlink.pro/) | [A cross-chain DEX network](./zenlink.md) | [GitHub](https://github.com/zenlinkpro/zenlink_dex_module) | ☐ | ☒ | ☒ |
| [Subscript](https://github.com/slickup) | [Substrate smart contract api and sdk in AssemblyScript](./subscript_lang.md) | [GitHub](https://github.com/slickup/subscript) | ☐ | ☒ | ☒ |
-| [Tesseract](https://tesseract.one/) | Swift API | [GitHub](https://github.com/tesseract-one) | ☐ | ☒ | ☐ |
+| [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/) | [Vedar: Auto-funded public P2P infrastructure (APPI)](https://github.com/w3f/General-Grants-Program/blob/master/grants/rfp-responses/appi.md) | [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](./sup.md) | [GitHub](https://github.com/clearloop/sup) | ☐ | ☒ | ☒ |
| [Shard Labs](https://shardlabs.io) | [Tip or Donate KSM Embeddable Button](./KSM-embeddable-tip-or-donate-button.md) | [GitHub](https://github.com/Shard-Labs) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 6 - Q2 2020
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :-------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :-------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [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](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/YieldScan.md) | [GitHub](https://github.com/buidl-labs) | ☐ | ☒ | ☒ |
@@ -634,12 +678,12 @@ Besides, **there is a clear difference between an application being accepted and
| [Zondax](http://zondax.ch/) | Ledgeracio: A command-line tool and Ledger app designed for staking operations | [GitHub](https://github.com/paritytech/ledgeracio) | ☐ | ☒ | ☒ |
| [Dipole Tech](https://www.dipole.tech) | [Dipole Oracle: Distributed energy resource management](./DipoleOracle.md) | [GitHub](https://github.com/DipoleTech/dipole-oracle) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 5 - Q1 2020
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :---------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :---------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [Bifrost](https://bifrost.finance/) | [EOS interoperable bridge](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/bifrost_network.md) | [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) | ☐ | ☒ | ☒ |
@@ -678,14 +722,14 @@ Besides, **there is a clear difference between an application being accepted and
| [Lyken](https://lyken.rs/) | [Rust trait system revamp](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/rust_trait_system_revamp.md) | [GitHub](https://github.com/LykenSol) | ☐ | ☒ | ☐ |
| [Chorus One](https://chorus.one/) | Grandpa light client in Tendermint | [GitHub](https://github.com/ChorusOne) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
## 2019
### 🏄 Wave 4 - Q4 2019
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :----------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :----------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [Genesis Lab](https://genesislab.net/) | Validator Tracker | [GitHub](https://github.com/genesis-lab-team) | ☐ | ☒ | ☒ |
| [Usetech](http://usetech.com/blockchain.html) | [Substrate API in .NET](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/dotnet_api.md) | [GitHub](https://github.com/usetech-llc/polkadot_api_dotnet) | ☐ | ☒ | ☒ |
| [BlockX Labs](http://blockxlabs.com/) | [Enzyme Browser extension wallet](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/Enzyme.md) | [GitHub](https://github.com/blockxlabs/enzyme) | ☐ | ☒ | ☒ |
@@ -711,14 +755,14 @@ Besides, **there is a clear difference between an application being accepted and
| [HashQuark](https://www.hashquark.io/) | Validator Dashboard | [GitHub](https://github.com/hashquark-io) | ☐ | ☒ | ☒ |
| [Stacktical](https://stacktical.com/) | [Performance Management Runtime Modules](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/predictive_performance_management_runtime_module.md) | [GitHub](https://github.com/Stacktical) | ☐ | ☒ | ☐ |
| [Sean Young](https://www.mess.org/) | Solidity to WASM compiler | [GitHub](https://github.com/hyperledger-labs/solang) | ☐ | ☒ | ☒ |
-| [Chain Security](https://chainsecurity.com/) | Tool for validating correctness of Polkadot runtimes | [GitHub](https://github.com/ChainSecurity/polpatrol) | ☐ | ☒ | ☒ |
+| [Chain Security](https://chainsecurity.com/) | Tool for validating correctness of Polkadot runtimes | [GitHub](https://github.com/ChainSecurity/polpatrol) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 3 - Q3 2019
| Team | Project | Link | Terminated | First Delivery | Completed |
-| :------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :--------- | :------------: | :-------: |
+| :------------------------------------------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------- | :---------: | :------------: | :-------: |
| [Supercomputing systems](http://scs.ch/) | [Substrate Rust API client](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/substrate-api-client.md) | [GitHub](https://github.com/scs/substrate-api-client) | ☐ | ☒ | ☒ |
| [NGRAVE](https://ngrave.io/) | [Substrate Hardware Wallet Integration](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/ngrave_substrate_1.md) | | ☐ | ☒ | ☐ |
| [Caelum Labs](https://caelumlabs.com/) | [Decentralised identity modules](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/Self%20Sovereign%20Identity%20layer%20as%20a%20Polkadot%20runtime.md) | | ☐ | ☒ | ☐ |
@@ -734,12 +778,12 @@ Besides, **there is a clear difference between an application being accepted and
| [Phala.Network](https://phala.network/) | [pLibra, Privacy Bridge between Polkadot and Libra chain](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/pLIBRA.md) | [GitHub](https://github.com/Phala-Network/) | ☐ | ☒ | ☐ |
| [Wiv](http://wiv.io/) | Supply chain modules and front-end UI | [GitHub](https://github.com/wivtech) | ☒ | ☐ | ☐ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 2 - Q2 2019
| 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) | ☐ | ☒ | ☒ |
| Substrate Java API | Java version of our JS API | [GitHub](https://github.com/polkadot-java) | ☐ | ☒ | ☒ |
| [Starlog](https://pact.care/) | [A metadata chain for IPFS](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/starlog.md) | [GitHub](https://github.com/PACTCare/Starlog) | ☐ | ☒ | ☐ |
@@ -753,12 +797,12 @@ Besides, **there is a clear difference between an application being accepted and
| [Mailchain](https://mailchain.xyz/) | a Multi-Blockchain Messaging Application | [GitHub](https://github.com/mailchain) | ☐ | ☒ | ☒ |
| [Usetech](http://usetech.com/blockchain.html) | [Polkadot C++ API](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/cpp_api.md) | [GitHub](https://github.com/usetech-llc/polkadot_api_cpp) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
### 🏄 Wave 1 - Q1 2019
| 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) | ☐ | ☒ | ☒ |
| [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) | ☐ | ☒ | ☒ |
@@ -770,4 +814,4 @@ Besides, **there is a clear difference between an application being accepted and
| [Protos](http://protosmanagement.com/) | Open Source Node Explorer | [GitHub](https://github.com/protos-research/polkadot-node-explorer) | ☒ | ☒ | ☐ |
| [Supercomputing Systems](https://www.scs.ch/) | [Substrate Transaction Privacy using Intel SGX](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/substrate_sgx_proposal.md) | [GitHub](https://github.com/scs/substraTEE) | ☐ | ☒ | ☒ |
-[🔝](#2023)
+[🔝](#top)
diff --git a/applications/infimum.md b/applications/infimum.md
new file mode 100644
index 00000000000..99a6f68c89a
--- /dev/null
+++ b/applications/infimum.md
@@ -0,0 +1,230 @@
+# Infimum
+
+- **Team Name:** Apollos Collective
+- **Payment Address:** 0x9c10EbAEB989CFd239679d47B9100dc4ad57A536 (ERC20 USDC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+This application is in response to the [anti-collusion infrastructure RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/anti-collusion_infrastructure.md).
+
+### Overview
+
+Helping to empower the realization of trust in, and verification of, voting systems within Substrate parachains.
+
+The goal of this proposal is to provide a minimum viable implementation of Vitalik Buterin’s [“Minimal Anti-Collusion Infrastructure”](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) as a substrate pallet and CLI (for performing off-chain work, i.e. encrypting votes, processing messages, and generating proofs).
+
+The scope of this proposal is intended to be a proof of concept, of which contributes to the development of a genuine *minimal* anti-collusion infrastructure within the Substrate ecosystem.
+
+Governance, and by extension voting systems, are critical facets of society at large and have become a crucial value proposition of many blockchain applications. It is therefore imperative to develop systems which not only promote a sense of underlying trust, but also can intrinsically verify their own integrity.
+
+The team is interested in cryptographic voting as a research domain. They would like to further explore this area in order to provide a meaningful contribution to the community. Refer to “Future Plans” section to preview how we’d like to see this project evolve.
+
+### Project Details
+
+There are two primary deliverables outlined in this proposal:
+
+1. A Substrate pallet which facilitates the voting apparatus and on-chain verification of poll results, and;
+
+2. A CLI tool to facilitate the generation of arguments passed to the methods exposed by the pallet.
+
+The goal of this system is to deincentivize collusion between participants given that any participant can secretly change or nullify their vote.
+
+
+
+Deliverables:
+
+1. Substrate pallet
+ 1. Description
+ 1. Facilitates transparency and provenance of poll interactions and outcome. Users can register as either coordinators or participants, create polls, and interact with polls. On-chain verification of zero-knowledge proofs (which have been generated off-chain) that establish the correctness of the poll tallying computations (which have been performed off-chain) must occur prior to the acceptance of, and publishing of poll outcome.
+ 2. Public methods
+ 1. `registerAsCoordinator` Permits the caller to create polls, and stores their (public) keys.
+ 2. `rotatePublicKey` Permits a coordinator to rotate their public,private keypair. Rejected if called during an ongoing poll.
+ 3. `rotateVerifyKey` Permits a coordinator to rotate their verification key. Rejected if called during an ongoing poll.
+ 4. `registerAsParticipant` Permits a user to participate in a poll. Rejected if called after voting period.
+ 5. `createPoll` Instantiates a new poll object with the caller as the designated coordinator. Emits an event with the poll data.
+ 6. `interactWithPoll` Inserts a message into the message tree for future processing by the coordinator. Valid messages include: a vote, and a key rotation. Rejected if sent outside of the timeline specified by the poll config. Participants may secretly call this method (i.e. from a different address) to override their vote, thereby deincentivizing bribery.
+ 7. `mergePollState` Used by the coordinator to compute roots of message state tree, which is used as a commitment value by the proof verification logic. Rejected if called prior to poll end.
+ 8. `commitProcessedMessages` Verifies the proof that the current batch of messages have been correctly processed and, if successful, updates the current verification state. Rejected if called prior to the merge of poll state.
+ 9. `commitTallyResult` Verifies the proof that the current batch of votes has been correctly tallied and, if successful, updates the current verification state. On verification of the final batch the poll result is recorded in storage and an event is emitted containing the result. Rejected if called before messages have been processed.
+ 3. Runtime storage
+ 1. Public key store: mapping between coordinators and their public keys (which are used by participants to encrypt their votes)
+ 2. Verifying key store: mapping between coordinators and their verifying keys used in the on-chain verification of proofs
+ 3. Poll store: mapping between poll id and the current state of the poll
+ 4. Poll message state: mapping between poll id and a merkle tree of secret participant messages (i.e. votes and/or nullifiers)
+ 5. Poll Result: mapping between poll id and outcome
+ 4. Dependencies
+ 1. We will rely on the [Groth16](https://eprint.iacr.org/2016/260.pdf) verifier provided by [bellman](https://github.com/zkcrypto/bellman/blob/main/src/groth16/verifier.rs) under the [MIT license](https://github.com/zkcrypto/bellman/blob/main/LICENSE-MIT).
+2. CLI tool
+ 1. Description
+ 1. Facilitates off-chain computations performed by participants and trusted operators. In particular, generating the values (e.g. encryption keys, proofs) required by the function signatures specified in the first deliverable (1.Susbtrate Pallet). This will be provided as a TypeScript library (in order to serve as a starting point for future integration into dApps) with a simple CLI wrapper.
+ 2. Technologies used
+ 1. Circom
+ 2. Typescript
+ 3. Node.js
+ 4. snarkjs
+ 3. Commands available to users
+ 1. `generateKeypair` Used by both participants and coordinator. Outputs a keypair used for encrypting and decrypting the messages which represent poll interactions.
+ 2. `generateProof` Used by the coordinator. Generates a proof of correctness for the current batch of message processing computations (including final vote tally).
+ 3. `encodeMessage` Used by participants. Accepts their vote as input, and outputs an encoded message which may only be decrypted and read by the coordinator.
+
+
+Poll lifecycle:
+
+1. Poll is created (by a coordinator). Prior to the start time of the poll:
+ 1. The coordinator may perform any permitted alterations to the poll configuration, or close the poll
+ 2. Individuals can begin to register as participants in the poll
+2. Poll starts:
+ 1. Coordinator may no longer preform any alterations to the poll (e.g. update signing key)
+ 2. Participants may interact with the poll (vote, revote, nullify vote, switch keys)
+3. Poll ends:
+ 1. Participants may no longer sign up or interact with the poll
+ 2. Coordinator may start to compute the outcome of the poll
+4. Poll result becomes “finalized” once:
+ 1. The coordinator publishes the result of the poll alongside proofs of the computations
+ 2. The result of the poll is committed to storage if and only if every proof passes verification
+ 3. At this point it is sensible for external actions to be taken in response to the outcome of the poll
+
+Constraints and limitations of the deliverables to be aware of:
+
+- A coordinator may only manage a single poll at a time (there may be multiple coordinators each with their own poll at any given time)
+- Users can only cast a vote of weight 1
+- Votes must be processed, and tallied, in batches
+- Non-transparent proof system (Groth16); requires a trusted setup
+
+We intend to improve upon these limitations in future work (see the section below).
+
+### Ecosystem Fit
+
+- Useful in governance schemes, e.g. crowd funding applications.
+- The target audience is parachain developers, e.g. a candidate integration could be the [imbue network](https://github.com/ImbueNetwork/imbue).
+- The overall intended trajectory is to help establish a sense of integrity within democratized systems. Participants in these systems are empowered to verify by default.
+- The team is not aware of any projects in the Substrate/Polkadot/Kusama which are currently attempting to achieve feature parity (or beyond) with MACI in the Ethereum ecosystem.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Rhys Balevicius
+
+### Contact
+
+- **Contact Name:** Rhys Balevicius
+- **Contact Email:** rhys@apollos.tech
+- **Website:** [https://rhys.tech](https://rhys.tech)
+
+### Legal Structure
+
+- **Registered Address:** 173 Presidial Avenue, Oshawa, ON Canada
+- **Registered Legal Entity:** Apollos Web3 Collective Inc.
+
+### Team's experience
+
+Rhys Balevicius is a software developer with over half a decade of professional experience in full-stack development, software design, and software architecture in various industries, of which include blockchain technologies and fintech. He is also currently studying Mathematics and Computer Science at University of Toronto.
+
+He is a founding software engineer at Dropverse, which is a gamified blockchain-based app where users can collect tokens, participate in drops, etc. in the real world. It is primarily integrated with the Ethereum ecosystem (in particular, there is currently support for any EVM compatible chain). Major achievements in this role include building a microservice that relay meta-transactions originating from user custodial wallets.
+
+Rhys also has previous experience in research and development, and some of this work has been patented. In particular, he designed and implemented a novel algorithm which utilized sequential image recognition in order to synchronize secondary content with the current timestamp of a video. The patent can be found here: [https://patents.google.com/patent/US11082679B1/en?oq=US11082679B1](https://patents.google.com/patent/US11082679B1/en?oq=US11082679B1)
+
+### Team Code Repos
+
+The majority of Rhys’ work has been client-based work and is closed-source. His interest in other projects has led him to also contribute to various open-source projects, some of which can be found here:
+
+- [https://github.com/cytoscape/cytoscape.js](https://github.com/cytoscape/cytoscape.js)
+- [https://github.com/rhysbalevicius/huh](https://github.com/rhysbalevicius/huh)
+- [https://github.com/rhysbalevicius/lipsync](https://github.com/rhysbalevicius/lipsync)
+
+GitHub profile: [https://github.com/rhysbalevicius](https://github.com/rhysbalevicius)
+
+
+### Team LinkedIn Profiles (if available)
+
+- **Rhys Balevicius:** [https://www.linkedin.com/in/rhys-balevicius/](https://www.linkedin.com/in/rhys-balevicius/)
+
+
+## Development Status :open_book:
+
+This application is in response to the [anti-collusion infrastructure RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/anti-collusion_infrastructure.md).
+
+Development status will be found over at [https://github.com/rhysbalevicius/infimum](https://github.com/rhysbalevicius/infimum). This is empty at the time of submission.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 6 months
+- **Full-Time Equivalent (FTE):** 0,5 FTE
+- **Total Costs:** $27,000
+
+### Milestone 1 — Voting apparatus without verification
+
+- **Estimated duration:** 2 months
+- **FTE:** 0,5
+- **Costs:** 9,000 USD
+
+| Number | Deliverable | Specification |
+| --- | --- | --- |
+| 0a. | License | MIT |
+| 0b. | Documentation | Inline documentation. Basic guide explaining how to interact with the pallet will be provided in the README. |
+| 0c. | Testing | Unit tests, GitHub actions CI workflow, and brief guide for running tests locally |
+| 0d. | Docker | Dockerfiles and docker-compose.yml for running a development environment which locally spins up a node and frontend template for observing events, calling pallet extrinsics, and performing state queries. |
+| 1. | Substrate pallet | Methods 1.ii.a to 1.ii.i (listed under deliverables in the project overview) without verification functionality provided by Groth16 proving system. |
+
+### Milestone 2 — On-chain verification logic and circuits
+
+- **Estimated Duration:** 2 months
+- **FTE:** 0,5
+- **Costs:** 9,000 USD
+
+| Number | Deliverable | Specification |
+| --- | --- | --- |
+| 0a. | License | MIT |
+| 0b. | Documentation | Inline documentation. Amendment to the original guide explaining the requirements for satisfying the verification logic. |
+| 0c. | Testing | Unit tests for methods added. Updated unit tests for amended methods. |
+| 1a. | Pallet: verification methods | Private methods for verifying proofs which have been generated off-chain by the CLI delivered in Milestone 3. Relies on the verification logic provided by bellman (https://github.com/zkcrypto/bellman). |
+| 1b. | Pallet: method modifications | Modifications to methods 1.ii.h and 1.ii.i (listed under deliverables in the project overview) to call the private verification methods defined in Milestone 2.1.a — these modifications will guard against storage updates in the case that verification fails, and publish the final poll outcome in the case of success. |
+| 2. | Circom circuits | Fork of MACI circuits defined here (https://github.com/privacy-scaling-explorations/maci/tree/master/circuits/circom) and licensed under MIT, amended as necessary for consumption within our off-chain proof generation pipeline. |
+
+### Milestone 3 — CLI tool and docsite
+
+- **Estimated Duration:** 2 months
+- **FTE:** 0,5
+- **Costs:** 9,000 USD
+
+| Number | Deliverable | Specification |
+| --- | --- | --- |
+| 0a. | License | MIT |
+| 0b. | Documentation | Inline documentation. Instructions for setting up and interacting with the CLI will be provided in the README. |
+| 0c. | Testing | Integration test scripts will be provided. |
+| 0e. | Article | We will provide an article directed towards parachain developers detailing: the motivation and general use case, an overview of the individual components of the system, the poll lifecycle, limitations and trust assumptions of the system, as well as an open invitation to contribute to the project. |
+| 1a. | TypeScript library | A library which exposes the functionality described in 2.iii.a to 2.iii.c (listed under deliverables in the project overview), as well as all related helper functions. |
+| 1b. | CLI for operators | CLI wrapper around 1a. Provides command line accessibility to the functionality required by operators to successfully interact with the pallet. |
+| 1c. | CLI for participants | CLI wrapper around 1a. Provides command line accessibility to the functionality required by participants to successfully interact with the pallet. |
+| 2a. | Docsite | We will package the article in 0e., all documentation, and all necessary setup and usage instructions into a readable and user friendly docsite. This will be hosted and associated with the project under the URL section of the repository as well as linked to in the README. |
+| 2b. | Voting Example | The docker-compose.yml will be updated to (optionally) provision a simple coordinator script (using Node.js and TypeScript) which manages an example poll. |
+| 2c. | Voting Tutorial | We will provide a tutorial which provides explicit step-by-step instructions on how to setup and interact with the voting example. |
+
+
+## Future Plans
+
+1. Experimentation with alternative architectures
+ 1. In particular, we are interested in architectures which support on-chain tallying utilizing partial or fully homomorphic encryption, and verifiable computation schemes such as [Rinnochio](https://eprint.iacr.org/2021/322.pdf?ref=blog.icme.io).
+ 2. Secure multi-party computation architecture which relies on multiple coordinators; this would enable complete secrecy of individual voter preferences. Ideally this would be combined with (1.i).
+2. Features and enhancements to deliverables
+ 1. Integration of transparent zk-SNARKS
+ 2. Reduce number of extrinsic calls required in the tallying phase, e.g. with [Nova](https://github.com/microsoft/Nova)
+ 3. Support for different voting schemes, e.g. quadratic, ranked choice
+3. Additional systems and example integrations
+ 1. Off-chain worker (and potentially a backend service) to automatically perform the message processing, tallying, and proof generation computations
+ 2. dApp which provides a rich user interface for creating and participating in polls
+ 3. Example ink! smart contract demonstrating how to interface with the pallet, e.g. a fungible-token contract wherein the voting power of a single participant corresponds to the number of tokens they own
+4. Outreach
+ 1. Obtain a security audit of infrastructure
+ 2. Network with faculty and peers with the aim of collaborating on research goals
+ 3. Seek out possible integrations with a parachain, e.g. [imbue](https://github.com/ImbueNetwork/imbue)
+
+Where appropriate, we would like to deliver some subset of these in follow up proposals.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Personal recommendation from a colleague.
diff --git a/applications/ink-analyzer-phase-2.md b/applications/ink-analyzer-phase-2.md
index 898c83f8471..b22129c52ca 100644
--- a/applications/ink-analyzer-phase-2.md
+++ b/applications/ink-analyzer-phase-2.md
@@ -27,9 +27,8 @@ This allows ink! developers to leverage Rust tooling like [clippy](https://doc.r
However, relying on only generic Rust language support in IDEs, code editors and other development tools has some significant limitations for the developer experience including:
-- No language support (e.g. diagnostic errors/warnings and quick fixes) for ink!'s domain specific semantic rules for smart contracts (e.g. exactly one `#[ink(storage)]` struct, at least one `#[ink(message)]` method and the same for `#[ink(constructor)]`, ink! attributes should be applied to items of the correct type e.t.c).
-- Inconsistent editor experience with issues like no code completion and/or hover content for some ink! attribute arguments (e.g `#[ink(payable)]`) because [macro expansion/name resolution and trait resolution are hard problems for generic IDE/code editor tools](https://rust-lang.github.io/compiler-team/working-groups/rls-2.0/#scope-and-purpose) (see also [https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html](https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html)).
-- No language support (e.g. go to definition, find references and rename/refactor) for [ink! specific syntax like paths in ink! attribute argument values (e.g. `env` values)](https://github.com/paritytech/ink/blob/v4.2.1/crates/ink/ir/src/ast/mod.rs#L19-L25).
+- No language support (e.g. diagnostic errors/warnings and quick fixes) for ink!'s domain specific semantic rules for smart contracts (e.g. exactly one `#[ink(storage)]` struct, at least one `#[ink(message)]` method and the same for `#[ink(constructor)]`, ink! attributes should be applied to items of the correct type, ink! `env` and `environment` argument values must `impl Environment` e.t.c).
+- Inconsistent editor experience with issues like no code completion and/or hover content for some ink! attribute arguments (e.g `#[ink(payable)]`) because [macro expansion/name resolution and trait resolution are hard problems for generic IDE/code editor tools](https://rust-lang.github.io/compiler-team/working-groups/rls-2.0/#scope-and-purpose) (see also [https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html](https://rust-analyzer.github.io/blog/2021/11/21/ides-and-macros.html)).
#### Solution
@@ -57,10 +56,11 @@ This stage of the project will improve ink! language support features across all
- Quick fixes for all existing diagnostic errors and warnings.
- ink_e2e macro support (i.e diagnostics, quickfixes, completions, code actions and hover content).
- Command for creating an ink! project and code/intent actions for inserting code stubs/snippets for relevant ink! entities.
-- Go to definition, find references and rename/refactor support for path-based ink! attribute argument values (i.e. `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]`).
-- Diagnostics that verify that the value of `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` are `impl Environment` as well as quick fixes to `impl Environment` for the target item where necessary.
- Inlay hints and signature help/parameter hints for ink! attribute arguments.
- Code/intent actions for "flattening" ink! attributes.
+- Diagnostics that verify that the value of `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` are `impl Environment` as well as quick fixes to `impl Environment` for the target item where necessary.
+- Diagnostics that verify chain extension `ErrorCode` types (and other chain extension utility types) implement required traits (e.g. `FromStatusCode` for `ErrorCode` types and SCALE code traits - i.e. scale's `Encode` and `Decode` and scale-info's `TypeInfo` traits - for error types, and input and output types of chain extension methods) as well as quick fixes to implement the required traits for the target items where necessary.
+- Diagnostics and quickfixes for implementing missing methods for ink! trait definition implementations.
#### Observation
@@ -203,9 +203,9 @@ You can find a full list of available resources in the [introductory blog post f
### Overview
-- **Total Estimated Duration:** ~7.75 months
+- **Total Estimated Duration:** ~8.5 months
- **Full-Time Equivalent (FTE):** 1
-- **Total Costs:** 54,400 USD
+- **Total Costs:** 59,600 USD
### Milestone 1 — Semantic analyzer: Quick fixes, ink_e2e macro support, project creation command and code/intent actions for inserting code stubs/snippets for relevant ink! entities
@@ -246,23 +246,22 @@ You can find a full list of available resources in the [introductory blog post f
- **FTE:** 1
- **Costs:** 10,800 USD
-| Number | Deliverable | Specification |
-|--------:|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| **0a.** | License | MIT or Apache 2.0 |
-| **0b.** | Documentation | I will provide detailed source documentation including rustdoc documentation that will be published to [docs.rs](https://docs.rs/) and a README file (published on [Github](https://github.com/), [crates.io](https://crates.io/) and [docs.rs](https://docs.rs/)) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library. |
-| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests. |
-| **0d.** | Docker | I will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
-| 1. | Rust crate update: Go to definition support for path-based ink! attribute argument values (i.e. `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]`) | I will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns the location where the item resolved by the path (if any) is defined (e.g. for `#[ink::contract(env=crate::MyEnvironment)]`, returns the location where `MyEnvironment` item is defined). While only `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` can be defined as paths at the moment, this utility will be defined generically for any path-based value used as an ink! attribute argument value. |
-| 2. | Rust crate update: Find references support for path-based ink! attribute argument values (i.e. `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]`) | I will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code and a cursor position as input and returns locations where the item resolved by the path (if any) is used (e.g. for `#[ink::contract(env=crate::MyEnvironment)]`, returns the locations where the `MyEnvironment` item is used). While only `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` can be defined as paths at the moment, this utility will be defined generically for any path-based value used as an ink! attribute argument value. |
-| 3. | Rust crate update: Rename/refactor support for path-based ink! attribute argument values (i.e. `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]`) | I will update the semantic analyzer crate to provide an interface that accepts ink! smart contract code, a cursor position and the new name for the item as input and returns the text edits for renaming the item resolved by the path (if any) across the workspace (e.g. for a `MyEnvironment` defined used in an `#[ink::contract(env=crate::MyEnvironment)]` and an `#[ink_e2e::test(environment=crate::MyEnvironment)]`, this renames `MyEnvironment` across all these locations). While only `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` can be defined as paths at the moment, this utility will be defined generically for any path-based value used as an ink! attribute argument value. |
-| 4. | Rust crate update: Diagnostics that verify that `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` are `impl Environment` as well as quick fixes to `impl Environment` for the target item where necessary | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` whose target item doesn't `impl Environment` as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that `impl Environment` for the target item where necessary. |
+| Number | Deliverable | Specification |
+|--------:|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **0a.** | License | MIT or Apache 2.0 |
+| **0b.** | Documentation | I will provide detailed source documentation including rustdoc documentation that will be published to [docs.rs](https://docs.rs/) and a README file (published on [Github](https://github.com/), [crates.io](https://crates.io/) and [docs.rs](https://docs.rs/)) providing general information about the library, instructions for installing and using the library and links to other documentation and resources related to the library. |
+| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests. |
+| **0d.** | Docker | I will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
+| 1. | Rust crate update: Diagnostics that verify resolution of path expressions for `env` for `#[ink::contract]` and `environment` for `#[ink_e2e::test]` argument values as well as quick fixes that either fix paths (e.g. by fixing or adding a qualifier) or suggest paths to valid item definitions (where possible) | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for resolution of path expressions for `env` for `#[ink::contract]` and `environment` for `#[ink_e2e::test]` argument values whose value doesn't resolve to any item as well as quick fixes in the form of code/intent actions that either fix paths (e.g. by fixing or adding a qualifier) or suggest paths to valid item definitions (where possible). |
+| 2. | Rust crate update: Diagnostics that verify that `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` are `impl Environment` as well as quick fixes to `impl Environment` for the target item where necessary | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for `env` values for `#[ink::contract]` and `environment` values for `#[ink_e2e::test]` whose target item doesn't `impl Environment` as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that `impl Environment` for the target item where necessary. |
+| 3. | Rust crate update: Diagnostics that verify that ink! trait definition `impl` blocks implement all associated methods as well as quick fixes for implementing missing methods where necessary | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for ink! trait definition `impl` blocks that don't implement all associated methods as well as quick fixes in the form of code/intent actions that add code stubs/snippets for implementing missing methods where necessary. |
-### Milestone 4 — Semantic Analyzer: Diagnostics, quick fixes and code/intent actions for chain extension `ErrorCode` type is `impl FromStatusCode` , and is not referred to using `Self::ErrorCode` anywhere in the chain extension or it's defined methods
+### Milestone 4 — Semantic Analyzer: Diagnostics, quick fixes and code/intent actions for chain extension `ErrorCode` type is `impl FromStatusCode` , and is not referred to using `Self::ErrorCode` anywhere in the chain extension or its defined methods
-- **Estimated duration:** ~3 weeks
+- **Estimated duration:** ~5-6 weeks
- **FTE:** 1
-- **Costs:** 5,600 USD
+- **Costs:** 10,800 USD
| Number | Deliverable | Specification |
|--------:|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
@@ -272,6 +271,8 @@ You can find a full list of available resources in the [introductory blog post f
| **0d.** | Docker | I will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
| 1. | Rust crate update: Diagnostics that verify that the chain extension `ErrorCode` type is `impl FromStatusCode` as well as quick fixes and code/intent actions to `impl FromStatusCode` for the target item where necessary | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for chain extension `ErrorCode` types whose target item doesn't `impl FromStatusCode` as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that `impl FromStatusCode` for the target item where necessary. |
| 2. | Rust crate update: Diagnostics for references to the chain extension's `ErrorCode` type using `Self::ErrorCode` in the chain extension (i.e. the `#[ink::chain_extension]` annotated `trait`) or it's defined methods (i.e. `impl` blocks for the chain extension `trait` in a `#[ink::contract]` annotated `mod`) as well as quick fixes to replace `Self::ErrorCode` usages with the `ErrorCode` type directly | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for references to the chain extension's `ErrorCode` type using `Self::ErrorCode` in the chain extension (i.e. the `#[ink::chain_extension]` annotated `trait`) or it's defined methods (i.e. `impl` blocks for the chain extension `trait` in a `#[ink::contract]` annotated `mod`) as well as quick fixes in the form of code/intent actions that replace `Self::ErrorCode` usages with the `ErrorCode` type directly. |
+| 3. | Rust crate update: Diagnostics that verify that the chain extension `ErrorCode` type implements SCALE codec traits (i.e. scale's `Encode` and `Decode` and scale-info's `TypeInfo`) as well as quick fixes and code/intent actions to implement the SCALE codec traits for the target item where necessary | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for chain extension `ErrorCode` types whose target item doesn't implement SCALE codec traits (i.e. scale's `Encode` and `Decode` and scale-info's `TypeInfo`) as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that implement SCALE codec traits for the target item where necessary. |
+| 4. | Rust crate update: Diagnostics that verify that input and output types of chain extension methods implement SCALE codec traits (i.e. scale's `Encode` and `Decode` and scale-info's `TypeInfo`) as well as quick fixes and code/intent actions to implement the SCALE codec traits for the target item where necessary | I will update the semantic analyzer crate by updating the existing interface that accepts ink! smart contract code as input and returns diagnostic errors and warnings to additionally return diagnostics for input and output types of chain extension methods whose target items don't implement SCALE codec traits (i.e. scale's `Encode` and `Decode` and scale-info's `TypeInfo`) as well as quick fixes in the form of code/intent actions that insert code stubs/snippets that implement SCALE codec traits for the target items where necessary. |
### Milestone 5 — Language Server: Updates #1
diff --git a/applications/ink-pallet-benchmarking-phase-2.md b/applications/ink-pallet-benchmarking-phase-2.md
index 5e9a02ec814..85c4a053567 100644
--- a/applications/ink-pallet-benchmarking-phase-2.md
+++ b/applications/ink-pallet-benchmarking-phase-2.md
@@ -5,7 +5,7 @@
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
## Project Overview :
-Proposal for Milestone 2 in the RFP titled [implementation-benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/implementation-benchmarking.md).
+Proposal for Milestone 2 in the RFP titled [implementation-benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/implementation-benchmarking.md).
### Overview
@@ -36,12 +36,12 @@ This will help new developers to decide the best tool to implement the logic.
### Legal Structure
-- **Registered Address:** B-7/8, Anmol Pride, Baner Road, Baner, Pune, Maharashtra 411045, India
-- **Registered Legal Entity:** Talentica Software India Pvt. Ltd.
+- **Registered Address:** Talentica Software Inc., 6200, Stoneridge Mall Road, Pleasanton, California 94588, USA.
+- **Registered Legal Entity:** Talentica Software Inc.
### Team's experience
-We have already worked on [implementation-benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/implementation-benchmarking.md) and delivered Milestones 1 and 2.
+We have already worked on [implementation-benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/implementation-benchmarking.md) and delivered Milestones 1 and 2.
### Team Code Repos
@@ -119,4 +119,4 @@ We are planning to submit another grant application towards Milestone 4 where we
## Additional Information :heavy_plus_sign:
Gautam Dhameja told us about the Grants program and encouraged us to apply to the same.
-We have already applied for and delivered Milestones 1 and 2 against [implementation-benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/implementation-benchmarking.md)
+We have already applied for and delivered Milestones 1 and 2 against [implementation-benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/implementation-benchmarking.md)
diff --git a/applications/ink-pallet-benchmarking.md b/applications/ink-pallet-benchmarking.md
index 465b8da8d46..b7cfe8b813b 100644
--- a/applications/ink-pallet-benchmarking.md
+++ b/applications/ink-pallet-benchmarking.md
@@ -5,7 +5,7 @@
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
## Project Overview :
-Proposal for the RFP titled [ink!/pallet/solidity performance benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/implementation-benchmarking.md).
+Proposal for the RFP titled [ink!/pallet/solidity performance benchmarking](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/implementation-benchmarking.md).
### Overview
There are multiple ways to implement the logic in substrate i.e using pallets or ink smart contracts, or even writing solidity code and compiling it to WASM with the help of a solang compiler. We have to benchmark the performance metrics of the logic implemented using each of the above methods. This will help new developers to decide the best tool to implement the logic.
diff --git a/applications/kodadot_assethub_nft_indexer_statemine_statemint.md b/applications/kodadot_assethub_nft_indexer_statemine_statemint.md
new file mode 100644
index 00000000000..637b4d09a1c
--- /dev/null
+++ b/applications/kodadot_assethub_nft_indexer_statemine_statemint.md
@@ -0,0 +1,206 @@
+# AssetHub NFT Indexer
+
+- **Team Name:** KodaDot
+- **Payment Address:** 1KxzJHoRJHi8EgWVhrGDueeyzg8PyihAvSL3NP6QMcxEve6
+- **[Level](https://github.com/w3f/Grants-Program#baby_chick-level-2):** 2
+
+### Overview
+
+The AssetHub Indexer is a GraphQL service designed to streamline the interaction with Uniques, NFT non-fungible assets, and fungible assets on AssetHubs (Statemine/Statemint). This service is specifically tailored to serve as a robust data layer for NFT-oriented dApps, leveraging the simplicity of GraphQL and REST API.
+
+In the current landscape, developers face challenges interacting with Uniques and Assets on Statemine due to the complexity and time-consuming nature of querying fungible and non-fungible assets on AssetHub. AssetHub Indexer aims to address these challenges by providing a user-friendly GraphQL interface, thus reducing the time and effort required to query these assets.
+
+The key advantages of the AssetHub Indexer include
+its focus on ease of use,
+versatility for a broad range of use cases, and
+its commitment to bringing Statemine utilization & documentation closer to developers.
+Furthermore, the AssetHub Indexer is a completely decentralized, open-source solution that respects user privacy by not collecting user data.
+
+By reducing the time required to query assets and providing a more user-friendly interface, the AssetHub Indexer aims to foster the growth and development of the Web 3.0 ecosystem in Polkadot.
+
+
+### Project Details
+
+The AssetHub Indexer is a state-of-the-art infrastructure tool designed to address developers' challenges when querying NFTs from the chain. Currently, developers are limited to querying NFTs in batches from RPC nodes, which can be time-consuming and inefficient for customer-facing products. This limitation often results in long waiting times and heavy device data loads.
+
+To overcome these challenges, we have developed the AssetHub Indexer. This tool leverages the power of GraphQL to provide a more efficient and user-friendly interface for developers. With the AssetHub Indexer, developers can easily query NFTs and build on top of the new [NFTs pallet by Parity](https://github.com/paritytech/substrate/blob/master/frame/nfts/src/lib.rs), opening up a wide range of potential use cases, such as creating [fandom shops](https://fandom.deno.dev) for art.
+
+Recognizing that many web developers may not have extensive experience with GraphQL, we have also built a TypeScript-based SDK that can be easily imported into any existing project. This SDK simplifies interacting with Uniques and Assets on Statemine, making it more accessible for developers of all skill levels.
+
+The AssetHub Indexer uses TypeScript and leverages the Squid framework (ArrowSquid) for data processing. It interacts with a Postgres database and provides a GraphQL interface for querying data. The project structure includes directories for generated model/server definitions, server extensions, data type definitions, and mapping modules. It also uses environment variables defined in a .env file or supplied by a shell for configuration.
+
+Currently, the AssetHub Indexer allows developers to interact with Uniques and Assets on Statemine using GraphQL. The project is designed to be as simple as possible, ensuring all tasks can be done quickly and without extended searching. We aim to reduce the time necessary to query fungible and non-fungible assets on AssetHub, making it easier for developers to build innovative and user-friendly decentralized apps.
+
+#### Architecture 🏗
+
+The architecture of the AssetHub Indexer is designed with simplicity and efficiency in mind, ensuring a seamless interaction with Uniques and Assets on Statemine.
+
+At the core of our architecture is TypeScript, a statically typed superset of JavaScript that adds optional types to the language. TypeScript ensures robustness and reliability in our codebase, allowing us to catch errors early in the development process and write more maintainable code.
+
+To handle data processing, we leverage the ArrowSquid framework. ArrowSquid is a powerful tool allowing us to process and index blockchain data efficiently. It provides a set of utilities for defining and running data processing tasks, making handling complex data processing requirements easier.
+
+Our project interacts with a Postgres database, a powerful, open-source object-relational database system that uses and extends the SQL language. Postgres provides us with the robustness, scalability, and performance we need to handle large amounts of data.
+
+
+
+On the architectural level, we have a few layers, as described in the picture above.
+We need to obtain the data for the correct function of our indexer. AssetHub indexer combines the SubSquid archive (the pre-indexed storage) and RPC node for the new data. When the indexer obtains a new event, it is automatically processed by the defined handler. As previously mentioned, we processed data stored in the Postgres DB.
+
+To expose the data to clients, we provide a GraphQL interface. GraphQL is a query language for APIs and a runtime for executing those queries with our existing data. It allows clients to ask for exactly what they need and nothing more, making it easier to evolve and enabling powerful developer tools.
+
+The project structure is organized into several key directories. The 'src/generated' directory contains model/server definitions created by codegen. The 'src/server-extension' directory contains a module with custom type-graphql-based resolvers. The 'src/types' directory contains data type definitions for chain events and extrinsics created by typegen. The 'src/mappings' directory contains the mapping module. The 'lib' directory contains compiled js files, reflecting the structure of the 'src' directory.
+
+Finally, the project configures environment variables, defined in a .env file or supplied by a shell. This approach allows us to easily manage and change the configuration without altering the codebase.
+
+The second state-of-the-art is our Client-first SDK called Uniquery. As we can see in the picture below, the only thing that client applications need to do is import the Uniquery package via ESM/CJS (Javascript targets). Once we have the Uniquery package, we can access query builder implementation (such as `client.getCollectionById(id)`). Additionally, because many developers are familiar with REST API, we build a similar fetch strategy without needing a third party (every client fetches data directly from SubSquid). The REST looks like this: `$fetch(/collectionById/${id}).`
+
+
+
+#### Technology Stack 💻
+
+- TypeScript
+- Node.js
+- Docker
+- SubSquid (ArrowSquid for Substrate)
+- Postgres
+- GraphQL
+
+
+### Ecosystem Fit
+
+The AssetHub Indexer is a crucial addition to the Polkadot and Substrate SDK ecosystem. It addresses the challenges developers often encounter when building on top of runtime pallets, particularly when interacting with Uniques, NFTs, and Assets on Statemine. The AssetHub Indexer provides a comprehensive NFT-oriented data solution, simplifying the development process and enhancing the efficiency of dApps within the ecosystem.
+
+Our solution stands out within the Polkadot and Substrate SDK ecosystem due to its user-friendly GraphQL interface and TypeScript-based SDK. These features streamline interaction with Uniques and Assets on Statemine, reducing the complexity of querying these assets.
+
+Moreover, the AssetHub Indexer is designed to be versatile, supporting a broad range of use cases. Developers can also leverage our [sub-scaffold UI](https://github.com/kodadot/sub-scaffold) template to bootstrap their projects quickly. This template, a forkable Substrate dev stack focused on rapid product iterations, accelerates the development process and allows developers to focus on creating innovative and user-friendly dApps, rather than getting bogged down in the initial setup.
+
+Our target audience for this proposal includes Web3 projects and blockchain developers, whether they are just starting out or already established within the Polkadot and Substrate SDK ecosystem. We believe the AssetHub Indexer can provide significant value to these developers, enabling them to build more efficient and user-friendly dApps like [KodaDot](https://kodadot.xyz/).
+
+AssetHub also plays significant for the [KodaDot](https://kodadot.xyz/) NFT marketplace, which is one of the main consumers for this indexer. Thanks to that, developers can find real-world examples of how to effectively make GraphQL queries and learn more about using Uniquery.
+
+
+Regarding competition within the Polkadot and Substrate SDK ecosystem, the AssetHub Indexer differentiates itself through its focus on NFT-oriented data solutions, user-friendly interface, and commitment to simplifying the development process. Including the sub-scaffold UI template further sets it apart, providing developers with a ready-to-use foundation for their projects. Moreover, the AssetHub Indexer is already being utilized by [Subsocial](https://twitter.com/SubsocialChain/status/1674435226334904320) and KodaDot, demonstrating its practical application and effectiveness. We plan to further promote the indexer within the ecosystem to onboard new developers and explore new solutions. These factors position the AssetHub Indexer as a unique and valuable tool within the Polkadot and Substrate SDK ecosystem, ultimately serving as a Common Good solution.
+
+
+## Team :busts_in_silhouette:
+
+### Team members (In order of joining time)
+
+- Matej Nemček - Project Lead
+- Viktor Valaštín - Developer
+
+### Contact 📞
+
+- **Contact Name:** Matej Nemček
+- **Contact Email:** matej.nemcek@geefu.net
+
+### Legal Structure
+
+- **Registered Address:** Proletarska cesta 4, 1000 Ljubljana, Slovenia, Europe
+- **Registered Legal Entity:** GenArt, Matej Nemček s.p.
+
+
+### Team's experience
+
+**Matej Nemček** is the Founder and CEO of [KodaDot](https://kodadot.xyz/). He has been instrumental in the growth and development of KodaDot, leading the team to create the best end-user experience on the Asset hub. Matej's leadership and vision have been pivotal in transforming KodaDot into a collaborative hub where creators, developers, and community members work collectively for decision-making.
+
+**Viktor Valaštín**, also known as Viki Val, is the Co-founder of KodaDot. He is responsible for the technical aspects of the project. Viktor has been working on implementing MoonBeam and MoonRiver NFT EVM smart contracts and enabling read-only access to existing components for seamless end-user interaction. His technical expertise has been crucial in successfully launching the Basilisk NFT Marketplace pallet in the Fall of 2022.
+
+Matej and Viktor are strongly committed to the Polkadot ecosystem and have demonstrated their ability to deliver high-quality, impactful projects. They bring a wealth of knowledge and experience to the AssetHub Indexer project. Their work has earned KodaDot the number one rank as a decentralized dapp in the Polkadot ecosystem on [Github](https://github.com/topics/polkadot). You can read more about their work and KodaDot's contributions to the Polkadot ecosystem on the [Polkadot Wiki](https://wiki.polkadot.network/docs/learn-nft-projects#kodadot).
+
+
+### Team Code Repos
+
+- [https://github.com/kodadot/stick](https://github.com/kodadot/stick)
+- [https://github.com/kodadot/nft-gallery](https://github.com/kodadot/nft-gallery)
+
+#### Team GitHub accounts 🧑💻
+
+- [Viktor Valaštín](https://github.com/vikiival)
+- [Matej Nemček](https://github.com/yangwao)
+
+
+### Team LinkedIn Profiles 🧑🎓
+
+- [Matej Nemcek](https://linkedin.com/in/mnemcek/)
+- [Viktor Valastin](https://linkedin.com/in/vikival/)
+
+
+## Development Status :open_book:
+
+- [github.com/kodadot/stick/milestone/1](https://github.com/kodadot/stick/milestone/1) - Milestone 1 track
+- [github.com/kodadot/stick](https://github.com/kodadot/stick) This is the repo for AssetHub Indexer.
+- [github.com/kodadot/uniquery](https://github.com/kodadot/uniquery) This is the repo for SDK.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Estimated duration:** 3 months ⌛️
+- **FTE:** 2 FTE
+- **Costs:** 30,000 USD 💰
+
+
+## Milestone 1 - AssetHub Indexer Implementation first part
+- **Estimated duration:** 3 months ⌛️
+- **FTE:** 2 FTE
+- **Costs:** 30,000 USD 💰
+
+
+| Sequence | Deliverable | Description |
+|----------|-----------------------------------------------------|---------------------------------------------------------------------------------------------------------------|
+| 0a. | Licensing | MIT License will be applicable. |
+| 0b. | Documentation | Comprehensive inline code documentation and an explicit README file to guide the project setup and execution.|
+| 0c. | Test Guidelines | Testing will cover major functionality with unit tests and provide a guide for executing these tests.|
+| 0d. | Docker Integration | A Dockerfile will enable the project to run within a Docker container. |
+| 1a. | Backward Compatibility Maintenance | Ensuring backward compatibility with current Uniques v1. |
+| 1b. | Collection Schema Development | Development of a GraphQL schema entity that represents the collection. |
+| 1c. | NFT Schema Development | Formulation and creation of a GraphQL schema entity representing Non-fungible tokens. |
+| 2. | Unique v1.1 Handlers | Implement a handlers to index buy, set_price events from the chain. |
+| 3. | NFT Pallet Handlers | Handler created for indexing create, mint, buy, set_price, transfer, burn events from the chain. |
+| 4a. | On-chain Attributes Schema Design | Development and design of a GraphQL schema entity representing on-chain attributes. |
+| 4b. | On-chain Attributes Handlers | Implementing a four handlers to index the creation and deletion of metadata set for collection and NFT from the chain. |
+| 5a. | Metadata Schema Development | Creating and designing a GraphQL schema entity representing metadata. |
+| 5b. | Metadata Handlers | Implementing a four handlers to index the creation and deletion of an attribute for collection and NFT from the chain. |
+| 5c. | Metadata IPFS Integration Handler | Design a handler to retrieve IPFS Metadata from the IPFS network. |
+| 5d. | Metadata IPFS Unification Handler | Design and integrate the library to uniform IPFS metadata into one format (OpenSea,TZIP-16,ERC-5773, FXhash) |
+| 6a. | NFT Royalties Schema Integration | Design and include royalty support within the GraphQL schema. |
+| 6b. | NFT Royalties Addition Handler | Implement a handler to add royalty into NFT. |
+| 6c. | NFT Royalties PAYOUT Handler |Creation of handler to index royalty payout events from the chain. |
+| 7a. | Fungible Assets Schema Creation |Design and formulation of a GraphQL schema entity representing fungible assets. |
+| 7b. | Fungible Assets Force Creation |Handlers will be developed to add system tokens like KSM/DOT into fungible assets. |
+| 7c. | Fungible Assets CREATE Event |An event handler for indexing the creation of a fungible event from a chain, such as (RMRK/USDT) will be developed.|
+| 7d. | Metadata Support for Fungible Assets | Implement a handler to add metadata to a fungible asset event from the chain. |
+| 7e. | Fungible Asset Allowlist Setup |Setting up allows list-based indexing of fungible assets. |
+| 8a. | Data Views Development |Construction of data views for efficient access to indexed data. |
+| 8b. | Implementing Metadata Caching Layer |Develop and retry IPFS metadata if un-indexed by Metadata IPFS Integration Handler. |
+| 9. | Transfer of Collection Ownership |Incorporate functionality to transfer collection ownership. |
+| 10a. | Collection settings Schema Design | Development and design of a GraphQL schema entity representing Collection settings |
+| 10b. | Collection settings handler | Implement a handler to add collection settings into data |
+
+
+## Future Plans 🔭
+
+Upon the successful deployment of the AssetHub Indexer, our team plans to continue refining and expanding its capabilities in response to user feedback and technological advancements. We have outlined several key enhancements and upgrades that we aim to implement:
+
+1. Development of an explorer to facilitate navigation within the NFT ecosystem.
+2. Introduction of collections functionality for systematic organization of NFTs.
+3. Creation of view modules to visually present NFT details.
+4. Establishment of user profiles to enable personalized user interfaces.
+5. Incorporation of constituent elements for individual NFT representation.
+6. Implement action components for functionalities like LIST, SEND, BUY, MINT, BURN, and Atomic Swap.
+7. Development of comprehensive statistical representations and analytics mechanisms.
+8. Introduction of rankings to highlight top-performing users, collections, or items.
+9. Personalization of the user interface to enhance the user experience.
+10. Maintenance of compatibility with runtime upgrades and changes in the Kusama/Statemine ecosystem.
+11. Regular updates to keep up with Substrate for continuous system enhancement.
+12. Management of upgrades to parachain runtime versions, including indexer enhancements and related costs.
+
+## Additional Information ➕
+
+
+The AssetHub Indexer project continues our team's various projects and implementations in the Polkadot ecosystem. We have already attracted interest from developers within the Polkadot and Kusama ecosystems. Notably, we have in 2019 previously received a grant from the W3F for creating Vue.js UI utilities, components, and libraries, details of which can be found [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/Vuejs_ui-components.md).
+
+This previous grant allowed us to reimplement keyring into Vue.js & TypeScript, demonstrating our hands-on experience with the polkadot.js.org/common utilities. The result of this work can be seen in the [web-based Subkey](https://subkey.netlify.com/) tool.
+
+We learned about the Grants Program through a personal recommendation. We believe that our project aligns well with the program's goals, and we are excited about the potential to further contribute to the Polkadot ecosystem.
diff --git a/applications/lastic-price-simulation-2.md b/applications/lastic-price-simulation-2.md
new file mode 100644
index 00000000000..fbabd775496
--- /dev/null
+++ b/applications/lastic-price-simulation-2.md
@@ -0,0 +1,171 @@
+# Coretime Sale Price Calculator by Lastic
+
+- **Team Name:** Lastic
+- **Payment Address:** 0x406FCE28194155A223bE3bF1F149D2Ee09c5E272 [USD-T Address]
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+
+## Project Overview
+
+### Overview
+The **Coretime Sale Price Calculator** represents a breakthrough in democratizing blockspace pricing within the Polkadot ecosystem. Developed in anticipation of Polkadot's Coretime, this tool will enable interactive, real-time simulations of Coretime pricing. Our objective is twofold: to offer the community a comprehensive view of Coretime pricing dynamics and to identify and mitigate potential vulnerabilities in the `broker pallet`'s pricing mechanisms, thereby safeguarding against unintended outcomes.
+
+### Project Details
+
+- **UI Components:** Our tool will incorporate interactive sliders and real-time graph visualizations, as currently demonstrated in our [GitHub repository](https://github.com/LasticXYZ/price-simulation). The application is approximately 60% complete and you can get a prieview of it's non final stage at [lastic.streamlit.app](https://lastic.streamlit.app/).
+- **Data Models:** We utilize adaptable Coretime pricing models, accessible through a user-friendly interface.
+- **Technology Stack:** Our technology stack includes Python and Streamlit for the web application, supplemented by Numpy and Matplotlib.
+- **Inspiration:** Our work is inspired by the [`Broker pallet`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/broker).
+- **Documentation:** Comprehensive documentation, including details on core components and interface interaction, will be available at our [docs site](https://docs.lastic.xyz/).
+- **PoC/MVP:** The current implementation, visible in [our repository](https://github.com/LasticXYZ/price-simulation), is live at [lastic.streamlit](https://lastic.streamlit.app/).
+
+### Ecosystem Fit
+
+- **Ecosystem Role:** Our project is strategically positioned to enhance understanding of the new blockspace pricing dynamics within the Polkadot ecosystem.
+- **Target Audience:** Our tool is designed for:
+ - **Substrate Developers:** to gain a better grasp of pricing dynamics.
+ - **Parachain Teams:** to adapt to the shift from slot auctions to Coretime renewals.
+ - **New Coretime Buyers:** giving them insights into Coretime pricing.
+ - **Polkadot Analysts and Analytics Providers:** in need of real-time Coretime data.
+ - **DOT Holders and the Wider Polkadot Community:** to understand the implementation of Coretime pricing.
+
+Our engagement with the community, as evidenced by the [Polkadot forum discussion](https://forum.polkadot.network/t/seeking-community-insight-on-coretime-price-simulation-model/4527), has already led to the identification of a potential vulnerability affecting new core purchases. Our goal is to refine the application further, ensuring that the Python code aligns with what is implemented within the `Broker pallet`, and to develop models that address and eliminate identified vulnerabilities.
+
+- **Addressing the Needs:** We provide a transparent, intuitive tool for simulating Coretime pricing, enabling teams to anticipate how demand and core availability might influence pricing.
+- **Comparison to Existing Solutions:** To our knowledge, there are no other initiatives aimed at simulating the Coretime pricing as implemented currently.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Phil Lucsok (aka Asynchronous Phil)
+- Aurora Makovac (aka Aurora Poppyseed)
+- Pierina Ponce
+
+### Contact
+
+- **Contact Name:** Phil Lucsok, Aurora Poppyseed, Pierina Ponce
+- **Contact Email:** plucsok@gmail.coml, aurora.makovac@gmail.com, pierinaponce1993@gmail.com
+- **Website:** [lastic.xyz](https://www.lastic.xyz/)
+
+### Legal Structure
+
+- **Registered Address:** Private
+- **Registered Legal Entity:** In progress
+
+### Team's experience
+
+#### **Phil Lucsok**:
+Phil began his career in web3 as a marketing and communications manager for a Bitcoin startup in Berlin in 2013 called [BitcoinsBerlin](https://web.archive.org/web/20220707055043/https://bitcoinsberlin.com/). There, he created marketing campaigns for multiple products including:
+- [All4BTC](https://all4btc.com/) - a one-stop shop for purchasing anything on Amazon or eBay with bitcoin
+- Bills4BTC (later [Bitwala](https://bitwala.com/), Nuri) - a SEPA-compliant payment method for holders of Bitcoin for regular payments
+- e4BTC - an electronics shop supporting purchases in Bitcoin
+
+After this, he worked for 3.5 years at [ResearchGate](https://www.researchgate.net/), a web2 social media platform for scientific researchers, where he learned skills in Product Management, Product Analytics, UX development and copywriting and design, and industry-standard growth practices.
+
+In late 2017, Phil joined Parity Technologies to lead technical communications on Ethereum and Polkadot. There he worked closely with developers to create promotional content for open-source products including Parity Ethereum, Parity Signer, Polkadot.js. It was between 2018 and 2020 where he represented Parity in Ethereum governance to help recover the stuck funds from the November 2017 multisig hack.
+
+He led the communications team for the first two years, growing the team from 1 to 12, where they created and executed the launch strategies for Polkadot, Kusama and Substrate. After that he joined the Ecosystem Success team to work with parachain teams to improve their communications and act as a liason between Substrate Builders Program teams and Parity.
+
+Phil currently works as a freelancer but is focused on leading [Missing Link](https://www.missing-link.io/)'s marketing, communications and governance strategies. He is also an active participant in Polkadot governance discussions on the Kusamarian and in ChaosDAO.
+
+*Note: Phil Lucsok has previously applied at the Web3 Foundation and has successfully completed Lastic Grant 1.*
+
+#### **Aurora Poppyseed**:
+Aurora's journey in the technological sphere stands out for her innovative approach and unwavering determination. With a foundation in Physics and Electrical Engineering, she transitioned into roles as varied as a Solutions Architect, focusing on electronics and low-level programming, to a Frontend Developer with a commitment to clean code and scalable frontend architectures.
+
+At [**Instrumentation Technologies**](https://www.i-tech.si/) in Nova Gorica, Slovenia, she led the design of intuitive GUIs for advanced measurement devices in particle accelerators and streamlined future development with a standardized Vue CLI-based web GUI framework. Her contribution as a Frontend Developer at [**Block Analitica**](https://blockanalitica.com/) involved engineering the frontend framework for the [**Ajna project**](https://www.ajna.finance/) initiated by the **MakerDAO team**, ensuring clean coding practices and an organized project structure for future open-source contributions.
+
+Aurora attended and graduated from the [**Polkadot Blockchain Academy**](https://www.polkadot.network/development/academy/) at UC Berkeley (engineering track), learning about the fundamentals of blockchain from leaders in this domain. Further enhancing her mark in the blockchain domain, Aurora offered her expertise to [**KodaDot**](https://kodadot.xyz/), a prominent multi-chain NFT marketplace, developing developer documentation and crafting both technical and non-technical articles to amplify the platform's presence.
+
+In the realm of community engagement and organization, Aurora co-organized the [**Polkadot Bled mini-conference**](https://www.meetup.com/subwork/events/292274713) and more recently, orchestrated a breakfast as a side event at sub0 aimed at [**women in Polkadot** in collaboration with **H.E.R. Dao**](https://lu.ma/dzuqx5nw). This gathering aimed to empower and bring together women leaders and enthusiasts in the Polkadot ecosystem. Furthermore, she's a staunch supporter of [**SubWork**](https://subwork.xyz/), a tech-centric coworking hub in the scenic Bled region and one of the pioneer **Polkadot hubs**.
+
+Now a freelance blockchain developer, Aurora champions women's representation in Polkadot and ardently supports community-driven blockchain initiatives.
+
+*Note: Aurora Poppyseed has previously applied at the Web3 Foundation and has successfully completed Lastic Grant 1.*
+
+### **Pierina Ponce**:
+
+In the dynamic landscape of technology, Pierina Ponce emerges as a versatile force, seamlessly transitioning from a background in health informatics to a burgeoning career in blockchain development.
+
+Pierina's academic journey commenced with a foundation in medicine, culminating in 2018. The pivotal moment occurred during her master's degree in health informatics from 2020 to 2022, where she discovered a profound interest in technology and programming. Eager to explore this newfound passion, Pierina took the leap and enrolled in the computer science program at the Universidad de Palermo in Buenos Aires.
+
+The year 2023 marked Pierina's initiation into the world of blockchain. Driven by a curiosity to delve deeper into this transformative technology, she sought knowledge and practical skills through the [Polkadot Blockchain Academy](https://polkadot.network/development/blockchain-academy/) at UC Berkeley. The immersive experience equipped her with the fundamentals of blockchain, setting the stage for her journey into the vibrant blockchain ecosystem.
+
+Pierina's enthusiasm for blockchain manifested in her active participation in hackathons. Notably, she contributed to the success of the [Women of Polkadot](https://twitter.com/WomenOfPolkadot) team in the encode ink! hackathon, where they secured victory by implementing a groundbreaking PSP34 smart contract. This achievement not only showcased her technical acumen but also underscored her commitment to fostering diversity and inclusion within the blockchain community.
+
+Currently employed as a data professional at [Ixpantia](https://www.linkedin.com/company/ixpantia/), a consulting Costa Rican business specializing in data science and data engineering projects, Pierina has become a catalyst for community growth.
+Pierina's unique trajectory blends her expertise in health informatics with her burgeoning skills in blockchain development. As a data professional, she brings a valuable perspective to the intersection of technology and healthcare, embodying the spirit of a true interdisciplinary innovator.
+
+*Note: Pierina Ponce has not previously applied for a grant at the Web3 Foundation.*
+
+---
+
+### Team's Repository & Online Presence
+
+**Organization's GitHub Page**:
+- [LasticXYZ Official Page](https://github.com/LasticXYZ)
+
+**Primary Repository for Grant Submission**:
+- [Coretime Price Simulation](https://github.com/LasticXYZ/price-simulation)
+
+**Team Member GitHub Profiles**:
+- [Phillux's GitHub](https://github.com/phillux)
+- [PoppyseedDev's GitHub](https://github.com/poppyseedDev)
+
+**LinkedIn Profiles**:
+- [Philip Lucsok](https://www.linkedin.com/in/philiplucsok)
+- [Aurora Makovac](https://www.linkedin.com/in/auroramakovac)
+
+## Development Status :open_book:
+
+Our project’s initial phase is already operational as seen on our [GitHub repository](https://github.com/LasticXYZ/price-simulation). It includes a basic UI and the fundamental functionality for Coretime price simulation.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 2-3 weeks
+- **Full-Time Equivalent (FTE):** 1.5 FTE
+- **Total Costs:** 6,000 USD
+
+### Milestone 1 — Creation of Coretime Price Simulator
+
+- **Estimated duration:** 2-3 weeks
+- **FTE:** 1.5
+- **Costs:** 6,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | The project will adopt the GPLv3 license, promoting open-source access and collaborative development. |
+| **0b.** | Comprehensive Documentation | In-depth documentation, inclusive of inline code commentary, will be available. This is further augmented by a detailed user guide on [Lastic's Docs](https://docs.lastic.xyz/), detailing usage, configuration settings, and installation procedures. |
+| **0d.** | Article on Simulator's Impact | Publication of a detailed article discussing the development process, key functionalities, and the potential influence of the Coretime Price Simulator within the Polkadot ecosystem. |
+| **1.** | Streamlit-based Application Development | Creation and launch of an interactive Streamlit-based web application, featuring user interface elements like sliders and input fields for dynamic simulation of Coretime pricing. |
+| **2a.** | UI - Dynamic Graph Visualization | Integration of live graph visualization using Matplotlib to display Coretime pricing trends, including visual representations of renewals, sales, and the impact of varying core numbers and price adjustments. |
+| **2b.** | UI - Interactive Sliders | Design and implementation of interactive sliders within the user interface, allowing adjustment of parameters such as start price, observe blocks, and quantity of cores sold per sale. |
+| **2c.** | UI - Configurable System Management | Development of an in-app configuration management system, enabling users to tailor settings like region length, bulk proportion, and renewal bump as per their requirements. |
+| **2d.** | UI - Flexible Price Calculation Options | Implementation of diverse price calculation methods, offering both linear and exponential models, with functionality for users to seamlessly toggle between these options. |
+| **2e.** | UI - Monthly Adjustment Feature | Capability for users to modify bulk coretime renewals and sales on a monthly basis, with each month equating to one region length. |
+| **3.** | Detailed Functionality Analysis | Comprehensive evaluation to ensure the Python-based pricing functionality aligns closely with the existing implementation in the [`Broker pallet`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/broker). |
+
+> Additional Note on 2d: While the exponential model is a deviation from the current [`Broker pallet`](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/broker) implementation, we believe it offers a valuable alternative for addressing potential vulnerabilities discussed in the [Polkadot Forum](https://forum.polkadot.network/t/seeking-community-insight-on-coretime-price-simulation-model/4527).
+
+---
+
+## Future Plans
+
+Our short-term goal is to integrate this tool into the Polkadot ecosystem, with continuous improvements based on community feedback.
+
+Long-term, we aim to establish Lastic as a core component of Polkadot’s blockspace marketplace, contributing to its broader adoption and utility.
+
+
+## Additional Information
+
+**How did you hear about the Grants Program?**
+
+- Phil's experience working at Parity informed him of the Web3 Grants program.
+- Aurora has learned about the Web3 Grants program during her time working at KodaDot.
+
+
+**Previous Grant Completion:**
+
+- We successfully delivered on [Lastic's Grant Application Number 1](https://github.com/w3f/Grants-Program/blob/master/applications/Lastic.md), focusing on creating a UI mockup for the Coretime Parachain and developing a static mockup with simulated data.
diff --git a/applications/maintenance/maintenance-template.md b/applications/maintenance/maintenance-template.md
index aeb5ffddb07..205a139cd7d 100644
--- a/applications/maintenance/maintenance-template.md
+++ b/applications/maintenance/maintenance-template.md
@@ -5,7 +5,7 @@
> See the [Maintenance Grants Process](https://github.com/w3f/Grants-Program#hammer_and_wrench-maintenance-grants) on how to submit a proposal.
- **Team Name:** Legal name of your team (e.g. JsonCorp)
-- **Payment Address:** In the case of fiat payment, please share your bank account privately with grants@web3.foundation via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here. Otherwise, provide the Polkadot (for USDC & USDT) or Bitcoin payment address. Please also specify the currency. (e.g. 0x8920... (USDC))
+- **Payment Address:** In the case of fiat payment, please share your bank account privately with grants@web3.foundation via your contact email (see below) and enter the date when you shared the information with us (e.g. Fiat 24.12.1971, 11:59) here. Otherwise, provide the Polkadot (for USDC & USDT) payment address. Please also specify the currency. (e.g. 0x8920... (USDC))
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1, 2 or 3
> ⚠️ *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.*
@@ -112,7 +112,7 @@ Our responsibilities:
- **Sprint/Period Duration:** Duration of the sprint/period (e.g. 4 weeks)
- **Total Duration:** Duration of the entire maintenance contract (e.g. 1 year)
- **Full-Time Equivalent (FTE):** Average number of full-time employees working on the project throughout its duration (see [Wikipedia](https://en.wikipedia.org/wiki/Full-time_equivalent), e.g. 2 FTE)
-- **Max budget per sprint/period:** Requested max budget in USD per sprint/period (e.g. 7,000 USD). Cost for each period need to be provided in USD; if the grant is paid out in Bitcoin, the amount will be calculated according to the exchange rate at the time of payment.
+- **Max budget per sprint/period:** Requested max budget in USD per sprint/period (e.g. 7,000 USD).
- **Hourly rate:** Amount of budget per hour, since it’s unlikely that the maintenance of the project requires the exact same workload each sprint.
> ⚠️ *Note that you will need to provide a comprehensive report of the work done at the end of each month, including the list of issues/bugs/pull requests worked on, time spent on each of these, & finally, the associated cost. The time allocation & price will likely vary from month to month, depending on the nature of the project you're contributing to. The report should be in the form of a Milestone Delivery, again like the typical procedure. W3F will make the payments only after the successful merge of each individual report.*
diff --git a/applications/orochi-network-orosign-part1.md b/applications/orochi-network-orosign-part1.md
index 3e92a275415..68a4ce7effb 100644
--- a/applications/orochi-network-orosign-part1.md
+++ b/applications/orochi-network-orosign-part1.md
@@ -1,7 +1,7 @@
# Orochi Network's proposal for research and development MPC ECDSA
- **Team Name:** Orochi Network
-- **Payment Address:** 0x2d309e09149259bD2b9a8C88985581B724d058b2 (ETH)
+- **Payment Address:** 167Zj4mv1jBTzJimSe7LngcRS7SBixsx3ZSCFr45Eo1SjWCY (USDT Polkadot)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
## Project Overview :page_facing_up:
@@ -69,8 +69,8 @@ Orosign project utilize cryptographic primitives and Multiparty Computation (MPC
### Legal Structure
-- **Registered Address:** OROCHI NETWORK PTE. LTD,68 CIRCULAR ROAD , #02-01 , SINGAPORE (049422)
-- **Registered Legal Entity:** OROCHI NETWORK PTE. LTD,68 CIRCULAR ROAD , #02-01 , SINGAPORE (049422)
+- **Registered Address:** Orochi Network LLC, Suite 305, Griffith Corporate Centre, Beachmont, Kingstown, Saint Vincent and the Grenadines (Postal code: VC0284)
+- **Registered Legal Entity:** Orochi Network LLC (ID: 1416 LLC 2021)
### Team's experience
diff --git a/applications/polkadot_analytics_platform.md b/applications/polkadot_analytics_platform.md
index 607059f2a25..1d8b6ccb34d 100644
--- a/applications/polkadot_analytics_platform.md
+++ b/applications/polkadot_analytics_platform.md
@@ -8,7 +8,7 @@
## Project Overview :page_facing_up:
-This proposal is aligned to the [RFP: Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/data_analysis_tools.md).
+This proposal is aligned to the [RFP: Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md).
Our R&D roadmap was conceived and kick-started before the creation of this RFP, which was presented to us during the course of our previous [research grant](https://github.com/w3f/Grants-Program/pull/1420). Nevertheless, we believe the proposed application (Polkadot Analytics Platform) is aligned with the RFP's requirements and main goals. Both aim at providing data analysis in a way that advanced non-technical users can consume, without requiring programming skills.
@@ -235,7 +235,7 @@ Our personal repos:
> links to improvement proposals or [RFPs](https://github.com/w3f/Grants-Program/tree/master/docs/RFPs) (requests for proposal),
-This proposal is aligned to the [RFP: Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/data_analysis_tools.md).
+This proposal is aligned to the [RFP: Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md).
Our R&D roadmap was conceived and kick-started before the creation of this RFP, which was presented to us during the course of our previous [research grant](https://github.com/w3f/Grants-Program/pull/1420). Nevertheless, we believe the proposed application (Polkadot Analytics Platform) is aligned with the RFP's requirements and main goals. Both aim at providing data analysis in a way that advanced non-technical users can consume, without requiring programming skills.
@@ -278,7 +278,7 @@ The total budget requested is US$ 10000 for two PhDs dedicating about 10 days of
### Milestone 1 — Knowledge-Base bootstrap
-In this milestone, the focus is on constructing the foundation of the analytics platform by creating a knowledge base. The goal is to define and implement the base components for the dev environment that will be the basis for the proposed platform. This includes evolving with POnto to address queries from the [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/data_analysis_tools.md) RFP and the Substrate-ETL project. An initial KB component (including triplestore database and basic API endpoint) will be developed to handle operations over POnto entities.
+In this milestone, the focus is on constructing the foundation of the analytics platform by creating a knowledge base. The goal is to define and implement the base components for the dev environment that will be the basis for the proposed platform. This includes evolving with POnto to address queries from the [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md) RFP and the Substrate-ETL project. An initial KB component (including triplestore database and basic API endpoint) will be developed to handle operations over POnto entities.
- **Estimated Duration:** 1 month
diff --git a/applications/polkadot_tests.md b/applications/polkadot_tests.md
index f912d7a713b..6b112106a60 100644
--- a/applications/polkadot_tests.md
+++ b/applications/polkadot_tests.md
@@ -7,7 +7,7 @@
## Project Overview :page_facing_up:
-This grant application falls under this [RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/polkadot-protocol_conformance_tests.md) and it aims
+This grant application falls under this [RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/polkadot-protocol_conformance_tests.md) and it aims
to develop a comprehensive test suite dedicated to assessing the compliance of Host implementations against the official Polkadot Protocol Specification.
### Overview
diff --git a/applications/polkamask.md b/applications/polkamask.md
new file mode 100644
index 00000000000..95b18d86c11
--- /dev/null
+++ b/applications/polkamask.md
@@ -0,0 +1,153 @@
+# PolkaMask
+
+- **Team Name:** PolkaGate
+- **Payment Address:** 17VdcY2F3WvhSLFHBGZreubzQNQ3NZzLbQsugGzHmzzprSG (USDT)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+
+## Project Overview :page_facing_up:
+
+[Polkagate](https://polkagate.xyz) is a dedicated team of Polkadot enthusiasts, actively involved in various aspects of community development. Our multifaceted contributions encompass the development of the Polkagate extension, as well as the efficient management of Polkagate's Polkadot and Kusama pools. Today, we are excited to present our latest initiative aimed at further enriching the Polkadot ecosystem.
+
+Introducing a revolutionary project with the vision of bridging the gap between the Polkadot ecosystem and the vast user base of Metamask, which boasts over 30 million users. We are committed to creating a seamless connection between these two vibrant communities, opening up new possibilities and opportunities for all involved.
+
+### Overview
+
+This project includes a signer Snap for the Polkadot ecosystem on MetaMask. It seamlessly integrates with all existing dApps without requiring any code modifications.
+The Signer is capable of signing not only Polkadot and Kusama extrinsics but also extrinsics from all other Substrate-based chains that align with Polkadot.js APIs.
+
+
+
+
+### Project Details
+
+We've prepared two demo videos [1](https://youtu.be/rclCgIFql7U) and [2](https://youtu.be/Ykil4x8d-dM), showcasing how Polkadot.js Apps an Staking dashboard are seamlessly connected with MetaMask using the Polkagate Signer Snap. This Snap flawlessly signs transactions, enhancing the user experience.
+
+Our project primarily utilizes JavaScript and TypeScript for development, ensuring accessibility and extendability for developers interested in contributing fresh ideas.
+
+While not a full-fledged extension like existing Polkadot ecosystem extensions such as Polkagate, Subwallet, or Talisman, our project has the potential to evolve into a comprehensive extension. This transformation is contingent on MetaMask expanding the capabilities of its Snaps, which some of them are currently accessible only to developers using MetaMask Flask.
+
+To uphold Snap security, MetaMask requires audits from selected teams. We are in the process of arranging these audits to ensure a high level of security. Additionally, we have plans to further enhance the extension's capabilities as soon as MetaMask provides Snaps with more functionalities.
+
+### Ecosystem Fit
+
+Where and how does your project fit into the ecosystem?
+
+Polkamask is designed to seamlessly integrate into the Polkadot and Kusama ecosystems by enhancing the interaction between MetaMask and Substrate-based chains. It introduces the Polkagate Signer Snap, allowing users to access and utilize the Polkadot and Kusama networks without any code modifications. It aims to bridge the gap between MetaMask and the Polkadot ecosystem, making it more accessible and user-friendly.
+
+Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
+
+Our primary target audience includes dApp developers and users who engage with the Polkadot and Kusama ecosystems through MetaMask. We aim to provide a solution that benefits developers by simplifying the integration process and offers users a smooth experience when interacting with Polkadot and Kusama dApps through MetaMask.
+
+What need(s) does your project meet?
+
+Polkamask addresses the need for seamless integration between MetaMask and Substrate-based chains like Polkadot and Kusama. It removes barriers and complexities in the user experience, allowing MetaMask users to access these ecosystems without having to modify existing dApps. This simplification and user-friendliness are essential for the broader adoption of Web3 technologies.
+
+Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
+
+There are existing projects in the Polkadot ecosystem that aim to enhance the user experience and accessibility. One example is the Polkadot wallet Snap developed by ChainSafe. However, it primarily supports Polkadot, Kusama, and Westend based on their codebase on GitHub. An important distinction is that integrating with this wallet Snap often requires dApps to undergo modifications to utilize the Snap, which can be a significant barrier to integration.
+
+In contrast, Polkamask differentiates itself by introducing the Polkagate Signer Snap. This Snap offers seamless integration with MetaMask, providing a user-friendly experience and eliminating the need for dApps to make code modifications. This ease of use and the ability to connect to Substrate-based chains without requiring code changes make Polkamask a unique and valuable addition to the ecosystem.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- [Kami Ekbatanifard](https://www.linkedin.com/in/ekbatanifard)
+- [Morteza Chalaki](https://www.linkedin.com/in/mchalaki)
+- [Mehran Pourvahab](https://www.linkedin.com/in/mehran-pourvahab)
+- [Martin Azarbad](https://www.linkedin.com/in/mehranazarbad)
+- [Amir Ekbatani](https://www.linkedin.com/in/amir-ekbatani-4b7399201)
+
+### Contact
+
+- **Contact Name:** Kami Ekbatanifard
+- **Contact Email:** ekbatanifard@gmail.com
+- **Website:** [polkagate.xyz](https://polkagate.xyz/)
+
+### Team's experience
+
+We are a dedicated team of Polkadot ecosystem enthusiasts with a strong track record of contributing to the blockchain space. Our mission is to make common Polkadot functionalities more accessible to end users. As the creators of the Polkagate extension, we have already demonstrated our commitment to enhancing the Polkadot experience.
+
+Our team members bring diverse expertise:
+
+ Kami: Holds a Ph.D. in software systems and works as a blockchain engineer and full-stack developer. Kami's experience includes developing applications for both private and public sources, such as centralized and decentralized crypto exchanges, NFT markets on Ethereum, and more. Kami also has a notable research track record, which you can explore [here](https://scholar.google.com/citations?user=pJ0HwqEAAAAJ&hl=en).
+
+ Morteza: Our CFO, Morteza, has an impressive background in financial systems, ensuring strong financial management for our projects.
+
+ Mehran: As a dedicated blockchain researcher, Mehran contributes to in-depth research within the Polkadot ecosystem.
+
+ Martin: Martin, a senior UX designer, who is working on enhancing the user experience of our softwares.
+
+ Amir: Amir, our meticulous test engineer, is responsible for implementing various tests to guarantee the smooth performance of our developments.
+
+With the successful development of the Polkagate extension, we have already established our commitment to the Polkadot ecosystem. Together, we are determined to continue making Polkadot more user-friendly and accessible, building on our collective expertise and passion.
+
+Previous Web3 Foundation Grants:
+
+ - Polkadot js plus Extension - [Details](./Plus.md)
+ - Polkadot js plus / Social Recovery Wallet (Follow-up Grant) - [Details](./Plus-social-recovery-wallet.md)
+ - Polkadot js plus / Nomination Pools (Follow-up Grant) - [Details](./Plus-follow-up.md)
+
+Note: Polkadot js plus has been rebranded as the Polkagate extension.
+
+### Team Code Repos
+
+- https://github.com/PolkaGate/polkagate-extension
+- https://github.com/PolkaGate/polkadot-Js-Plus-extension
+- https://github.com/Nick-1979/Eligibility
+- https://github.com/Nick-1979/fastUnstakeTest
+- https://github.com/Nick-1979/stuckTokens
+
+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/Nick-1979
+- https://github.com/AMIRKHANEF
+- https://github.com/mehran-pourvahab
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/ekbatanifard
+- https://www.linkedin.com/in/mchalaki
+- https://www.linkedin.com/in/mehran-pourvahab
+- https://www.linkedin.com/in/mehranazarbad
+- https://www.linkedin.com/in/amir-ekbatani-4b7399201
+
+
+## Development Status :open_book:
+
+While our project code is currently housed in a private repository due to its work-in-progress (WIP) nature, we have made two essential packages available for the community:
+
+ - @polkagate/snap: [NPM Link](https://www.npmjs.com/package/@polkagate/snap)
+ - @polkagate/extension-dapp: [NPM Link](https://www.npmjs.com/package/@polkagate/extension-dapp)
+
+
+These packages serve as initial contributions to our project and provide a foundation for what's to come. We look forward to further developing and sharing our work as it matures.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 3 months
+- **Full-Time Equivalent (FTE):** 2
+- **Total Costs:** 28,000 USD
+
+### Milestone 1 - Create PolkaMask
+
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense |
+| **0b.** | Documentation | Our documentation will include both inline code explanations and a comprehensive tutorial to guide users on how to work with the Polkagate Signer and MetaMask Snaps. This tutorial will effectively showcase the functionality of Polkamask.|
+| **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 what was done/achieved as part of the grant. |
+| 1. | Polkagate Signer (Metamask Snap) | We will develop a MetaMask Snap that intercepts user interactions with dApps and provides a user-friendly interface for signing transactions. |
+| 2. | Upgrading Polkadot extension-dapp | We will enhance the official Polkadot extension-dapp by adding Snap support to improve its functionality. |
+| 3. | Upgrading Polkadot-Cloud | We will integrate Metamask as a connection option within Polkadot-Cloud, expanding its compatibility and accessibility. |
+
+
+
+## Future Plans
+
+Our future plans for the project involve gradual expansion in alignment with new features released by MetaMask for Snaps. Our short-term focus includes utilizing, enhancing, promoting, and supporting the existing functionality. In the long term, we intend to continue adapting and extending the project to encompass a broader range of features, ensuring it evolves into a full-featured extension as MetaMask introduces new capabilities for Snaps.
\ No newline at end of file
diff --git a/applications/project_aurras_mvp_phase_2.md b/applications/project_aurras_mvp_phase_2.md
index accc4756723..cb9f659c9ac 100644
--- a/applications/project_aurras_mvp_phase_2.md
+++ b/applications/project_aurras_mvp_phase_2.md
@@ -1,7 +1,7 @@
# Project Aurras - MVP - Phase 2
- **Team Name:** HugoByte AI Labs Private Limited
-- **Payment Address:** 1G5Fo5KfLSopTFKPRDUZgeCSU5PNY2kkD5 (BTC)
+- **Payment Address:** Fiat 20.10.2023, 06:33 UTC
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
## Project Overview :page_facing_up:
diff --git a/applications/quantum-guard.md b/applications/quantum-guard.md
new file mode 100644
index 00000000000..b6f956a8c99
--- /dev/null
+++ b/applications/quantum-guard.md
@@ -0,0 +1,134 @@
+# Quantum Guard MVP
+
+> 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! See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal.
+
+- **Team Name:** Andrea Di Franco
+- **Payment Address:** Polkadot Asset Hub (USDC) 13jYU81g4FjBWX4ZMW2o42JCeneqB7xEHfs2muhPfW3RYkq
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Quantum computation is one of the biggest threats to every cryptographic system in the mid future, including blockchains. While the level of computational capabilities currently available for quantum computers aren't enough to break the cryptography behind any blockchain project yet, it's expected that this will be achieved in the next years, potentially way before than what's predicted.
+In order to be considered quantum-resistant, a blockchain must have the following characteristics:
+- Rely on quantum-resistant cryptographic primitives for every event that requires digital signatures, such as signing transactions;
+- Use a quantum-resistant communication protocol between nodes.
+
+On August 28th, 2023, the National Institute of Standards and Technology (NIST) issued an official document stating that 4 algorithms will be standardized as official PQC.
+[NIST Document available here](https://www.federalregister.gov/d/2023-18197/p-12)
+Among the selected algorithms, the document cites:
+ - CRYSTALS-KYBER algorithm for key exchange;
+ - CRYSTALS-Dilithium for asymmetric cryptography.
+
+QuantumGuard is a project that aims to create a safe quantum-resistant parachain in the Polkadot environment, based on NIST-selected quantum-safe cryptographic algorithms. The parachain will enable the use of NIST-standardized quantum-safe algorithms for every crucial cryptographic operation, such as key generation, signing transactions and communication between nodes.
+
+
+### Project Details
+
+The current Grant application will focus on enabling quantum-safe cryptography for address generation and signing transaction in a Substrate-based blockchain. In order to achieve this, the development will focus on two objectives:
+
+- Customization of Substrate crypto pallet in order to use CRYSTALS-Dilithium for addresses generation and signing transaction: in order to achieve this, it'll be used the Rust integration of CRYSTALS-dilithium algorithm as published in the following Github repository: https://github.com/pq-crystals/dilithium under Apache 2.0 License;
+- A custom version of browser wallet extension (Polkadot.js or Talisman) which allows to store keyparis and sign transaction using CRYSTALS-Dilithium cryptography: this will be developed using the Javascript version of the CRYSTALS-dilithium algorithm published as npm package https://www.npmjs.com/package/dilithium-crystals under MIT License, adapting it for the use with a Hierarchical Deterministic wallet.
+
+### Ecosystem Fit
+
+The ultimate goal of the project is to provide a full parachain that will act as a vault for every other parachain in the Polkadot environment, which do not use quantum-safe cryptography. Every address can bridge their asset to QuantumGuard and secure them, this way if the original blockchain gets attacked and informations get lost, they can still live in the quantum-safe vault.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Andrea Di Franco
+
+### Contact
+
+- **Contact Name:** Andrea Di Franco
+- **Contact Email:** difranco.developer@gmail.com
+
+### Legal Structure
+
+- **Registered Address:** Via Aniello Falcone 273, 80127 Napoli NA Italy
+- **Registered Legal Entity:** Individual
+
+### Team's experience
+
+Andrea Di Franco is a senior software developer and blockchain specialist, working in R&D for several EU-funded research projects involving blockchain, cryptography and digital identity. He's been working for 4 years in a European company deeply involved in digital transformation,
+studying and applying many different cryptographic algorithms such as:
+- Hashing functions SHA-2, SHA-3;
+- RSA asymmetric cryptography applied to digital identity and PKI infrastructure;
+- Elliptic curve cryptography algorithms, applied to different blockchains, such as SECP256K1, ED25519;
+- Ring signature schemes;
+- Omomorphic encryption.
+
+### Team Code Repos
+
+- https://github.com/andredif
+
+### Team LinkedIn Profiles (if available)
+
+- https://www.linkedin.com/in/andrea-di-franco/
+
+
+## Development Status :open_book:
+
+The development will start with the approval of the Grant application.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+* **Description** Development of QuantumGuard - MVP - Phase 0.5
+* **Total Estimated Duration:** 14 Person Weeks
+* **Full-time equivalent (FTE):** 1
+* **Total Costs:** 9,800 USDC
+
+### Milestone 1 — Quantum-safe cryptographic algorithms for keypairs
+
+- **Estimated duration:** 8 weeks
+- **FTE:** 1
+- **Costs:** 5,000 USDC
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | Documentation includes: Code Documentation, Configuration Documentation, and a basic **tutorial** that explains how a user can start a node and send test transactions. |
+| 0c. | The code will have unit-test coverage to ensure functionality; in the guide we will describe how to run the tests |
+| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
+| 1. | Substrate module: CRYSTALS-crypto | We will create a Substrate module that will enable the use of CRYSTALS-Dilithium as a cryptography algorithm for generating keypairs valid in the blockchain. |
+| 2. | Substrate chain | The new Substrate module enabling CRYSTALS-Dilithium cryptography will be used to scaffold a node of a new quantum-safe chain. |
+
+### Milestone 2 — Custom browser extension using quantum-safe keypairs
+
+- **Estimated Duration:** 6 weeks
+- **FTE:** 1
+- **Costs:** 4,800 USD
+
+| Number | Deliverable | Specification |
+| ------------- | ------------- | ------------- |
+| 0a. | License | Apache 2.0 |
+| 0b. | Documentation | Documentation includes: Code Documentation, Extension Documentation, Readme file |
+| 0c. | Testing Guide | The guide will explain how to install the extension and how to use it in order to send transactions |
+| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
+| 0e. | Article | A Medium article will be written, in order to explain the work done as part of the grant. |
+| 1. | Custom extension: X | We will create a custom version of crypto wallet as a browser extension, in order to be able to generate, store and use quantum-safe keypairs. |
+
+## Future Plans
+
+After the successful completion of the current Grant, the plan is to create a small team in order to bring the project to a further stage, on the path to a consolidate parachain project.
+
+Next plans include:
+* Implementation of post-quantum communication protocol between nodes, using NIST-selected CRYSTALS-KYBER algorithm;
+* Creation of a network of several QuantumGuard nodes;
+* Public testnet.
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Web3 Foundation Website
+
+* What work has been done so far?
+This is our first grant as a part of bringing innovation to the web3 Ecosystem.
+* Are there are any teams who have already contributed (financially) to the project?
+No
+* Have you applied for other grants so far?
+No
diff --git a/applications/sandox.md b/applications/sandox.md
index 357bbba1817..12c4640ebbe 100644
--- a/applications/sandox.md
+++ b/applications/sandox.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-This application is in response to the [Alternative javascript console for Polkadot JS API RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/alternative-polkadot-js-api-console.md).
+This application is in response to the [Alternative javascript console for Polkadot JS API RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/alternative-polkadot-js-api-console.md).
### Overview
@@ -33,7 +33,7 @@ Till then files and settings storage will be local and user’s code will be run
### Ecosystem Fit
-According to the [RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/alternative-polkadot-js-api-console.md) current polkadot js API console has some limitations, which we offer to overcome by creating the SanDOx IDE.
+According to the [RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/alternative-polkadot-js-api-console.md) current polkadot js API console has some limitations, which we offer to overcome by creating the SanDOx IDE.
## Team :busts_in_silhouette:
diff --git a/applications/sarp-basic-functionality.md b/applications/sarp-basic-functionality.md
index 485712cd299..c3b5d1acce2 100644
--- a/applications/sarp-basic-functionality.md
+++ b/applications/sarp-basic-functionality.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-This application is a response to the RFP [Static Analysis for Runtime Pallets](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/Static-Analysis-for-Runtime-Pallets.md)
+This application is a response to the RFP [Static Analysis for Runtime Pallets](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Static-Analysis-for-Runtime-Pallets.md)
### Overview
@@ -78,7 +78,7 @@ Github accounts of the team members
## Development Status :open_book:
-We will base our work on [MIRAI](https://github.com/facebookexperimental/MIRAI) and the RFP [Static Analysis for Runtime Pallets](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/Static-Analysis-for-Runtime-Pallets.md)
+We will base our work on [MIRAI](https://github.com/facebookexperimental/MIRAI) and the RFP [Static Analysis for Runtime Pallets](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Static-Analysis-for-Runtime-Pallets.md)
We have not started to work on this.
diff --git a/applications/signet.md b/applications/signet.md
new file mode 100644
index 00000000000..ac14a683010
--- /dev/null
+++ b/applications/signet.md
@@ -0,0 +1,260 @@
+# Signet - Talisman
+
+- **Team Name:** Paraverse Foundation
+- **Payment Address:** 128tk6D5CvYvGFtvjTgZT8yrD2wPWZyczBoj8LzkmGpTNbo9 (USDC/AssetHub)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+
+## Project Overview :page_facing_up:
+
+### Overview
+
+Signet is blockchain-native financial workflow management software for enterprises.
+
+The goal of Signet is to enable enterprises to perform blockchain operations such as treasury management, payments, staking and governance in a way that is friendly to non-technical users but include similar "best practice" risk management controls to how they may operate in web2 today.
+
+We believe enterprise adoption will be one of the central narratives of the transition to Polkadot 2.0, and the capabilities of the Signet platform will enable this to happen in Polkadot, enabling enterprises to feel comfortable to inject liquidity into the ecosystem.
+
+Signet is built natively on top of Substrate, including the multisig, proxy, governance and staking pallets, but adds an open-source self-hostable software layer on top that enables configurable workflows for the purpose of internal risk mititgation.
+
+Signet was initially created out of Talisman’s user research, which revealed that teams faced many difficulties and risked mistakes when trying to run their on-chain financial operations, and ended up choosing convenience over security. In mid 2023, the Signet team was formed within Talisman to focus on B2B and enterprise opportunities.
+
+We believe what we are proposing is a great candidate for W3F funding because of two reasons:
+
+1. The common good aspect of a documented, integratable Sign in with Substrate (SIWS) reusable component, coupled with the halo effect it will have on Substrate adoption by providing a new avenue for both existing web2 and current web3 developers to build for the ecosystem.
+2. The importance of usability for larger organizations, enterprises and institutional users, who find it difficult today to use overly technical tools such as Polkadot.js. We believe strongly that ease of use and understanding are extremely important when trying to achieve security, in practice, in an enterprise context, and by delivering this, Signet will enable liquidity to flow into the ecosystem.
+
+### Project Details
+
+We will first describe the architecture of the current system, and then the improvements and additions we plan to implement in the course of this grant.
+
+#### Architecture Overview
+
+Signet's architecture provides the ability to manage offchain enterprise workflows along with supporting data like address books in a secure manner. With access controls and the ability to self host the instance, clients can choose the level of security and privacy for their implementation.
+
+
+
+Our system is designed around the idea that a multisig unit is a keyless any proxy controlled by a Substrate multisig. We use a magic link system that encodes the proxy address and the member addresses of the multisig, which can then be shared with other signers to import it into their instance of Signet. The frontend is built in React and Typescript.
+
+Offchain data used to support Enterprise Workflows are stored in a Postgres Database via Hasura, which offers at least 2 levels of authorisation. Requests to access data in the database are authorised using a combination of on-chain and off-chain data to satisfy various business needs, followed by role based access control built into Hasura. Access is restricted so that the Hasura server is the only service that can call the database.
+
+We use Sign in with Substrate (SIWS) to authenticate users. This allows our backend to confirm that whoever claims to own an address and wants resources relevant to that address actually owns the address and is able to sign a challenge message to provide proof. SIWS has been created specifically for Signet, and is run in a nodejs sidecar.
+
+Signet is designed in a modular way, so that specific workflows or extrinsics can be have a custom UI that enables non-technical users to perform blockchain actions.
+
+The initial version of Signet was developed as part of a Polkadot Treasury Proposal and aimed at DAOs and smaller teams in Polkadot. We have since decided to focus on larger enterprises who require more complex workflows and risk mitigation.
+
+#### Key Focus Areas
+
+For the purpose of this grant, we are looking to build on top of the work and architecture presented above and address the following two issues:
+
+1. **No standard for Sign in with Substrate:** While other projects have built custom solutions for logging into an app using Substrate, there are currently no reusable components to make it easy for developers to build apps and services on top of Substrate login.
+2. **Improve existing UX for Selecting Validators:** Validator selection is currently difficult and error prone, and users have no easy way to double-check the addresses they are assigning in the process.
+
+The following diagram shows Signet as it is being built out currently (in black), as well as the additions enabled by this grant (in green).
+
+
+
+SIWS is a building block towards a shared address book for multisigs/organizations, which can enable migration of shared enterprise information from computer to computer or authorized person to authorized person, as well as allows for easier selection of validator addresses for all signers to leverage and is a key part of improving the experience of using Substrate-based proxy-multisigs.
+
+### Ecosystem Fit
+
+The project is built on Substrate, using Substrate native features. The goal of the project is to enable entities (corporations, asset managers, web3 companies etc.) to feel comfortable enough operationally to manage a significant amount of assets on Substrate.
+
+#### Target User
+The target audience is enterprises and larger organizations who require workflows and risk management in order to be comfortable to deploy capital into the Polkadot ecosystem. This may include enterprises already operating on-chain in Substrate, enterprises with a large web2 footprint, including, potentially, customers of Mythical Games, Aventus, Peaq, Energy Web, etc, or more traditional organizations evaluating moving into Substrate including, potentially, Deloitte, Sony or Toyota. Signet would allow C-Levels and Finance/Operations departments at these types of companies to feel comfortable integrating blockchain into their workflows.
+
+#### Similar Projects
+There are a number of multisig front-ends or multisigs in development in the Polkadot ecosystem, including: Multix, PolkaSafe, Saturn. While ostensibly there is an overlap in functionality related to being a multisig, Signet is designed to sit at a layer above the multisig and aimed at a different target audience:
+
+1. Signet is designed to be self-hostable to enable an organization to manage it's own off-chain data and workflows in a way that meets it's internal devops and security needs.
+2. Signet's main value-add is not simply to provide a more friendly multisig UX, but rather to enable an organization to implement their own workflows on top of the multisig process. It's likely that these workflows require, at least at this time, off-chain operations and data storage that enhance the underlying blockchain.
+3. Signet's direction is to become a platform that integrates with different multisig front-ends or multisig pallets, rather than competing with them.
+
+Regarding Sign in With Substrate, there are a few projects that have implemented bespoke methods of logging in with a Substrate keypair to their own dapps, however we believe these fall short of the user-friendly and developer-friendly needs to truly function as a component that can be reused, as well as to grow an ecosystem of apps and services on top of a Substrate login:
+
+- The messages signed are unintelligble bytes, rather than human readable messages
+- The format of the login has not been standardized/structured to enable implementation into wallets/signers
+- The component(s) are not packaged, available and deployable in developer-friendly ways
+- The documentation doesn't exist that enables a developer to implement the sign-in functionality.
+
+Regarding managing a staking position, most institutional holders still use Polkadot.js, as it is the most longstanding and trusted tool, though due to a confuing UI, using it can easily lead to confusion or potential mistakes.
+
+Alternate methods of managing staking positions, such as Polkadot Staking Dashboard, are available to users, but they are focused on retail usage at the current time, and do not support the more complex needs of institutional or enterprise users.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Team leader: William Chen
+- Team members: Nipsey, Glide, Chris Ling
+
+### Contact
+
+- **Contact Name:** William Chen
+- **Contact Email:** william@talisman.xyz
+- **Website:** https://talisman.xyz
+
+### Legal Structure
+
+- **Registered Address:** 2nd Floor Whitehall House, 238 North Church Street, George Town, PO Box 31489, Cayman Islands KY1-1206
+- **Registered Legal Entity:** Paraverse Foundation
+
+### Team's experience
+
+William is the COO of Talisman. He has first hand experience with intricacies of managing fully-on-chain entities, including treasury management, distributed workforce compensation processes and other internal financial and operational processes on both Polkadot and Ethereum.
+
+Nipsey is the co-founder and CTO of Talisman. Nipsey leads the effort around Talisman's nomination pools, which, together, are the largest in Polkadot, containing over 3 million DOT.
+
+Glide has led a number of products in Web3 at Defi projects such as Sushi, DAOs including DeepDAO and on NFTs from 2017 before the ERC-721 standard. She has been a key contributor to Web3 product design community from 2018, speaking at events including Web3 Summit on User Data Design Considerations & Devcon on User testing practices for Mechanism Design. Prior to that, she led new product development and core banking transformations at large Banks and Financial institutions including BNP Paribas, Australian Super and UBS often working with industry regulators, compliance and security. Most recently she has worked in Defi, specialising in tokenomics design and implementing Multisigs on Ethereum to manage token distribution for DAOs and Treasuries.
+
+Chris has been a lead developer at a project in the Ethereum ecosystem, was previously on the identity team at Grab -- the only p0 (e.g. mission critical) team at the company -- and has worked on numerous web2 auth projects. In his spare time, he dabbles in MEV, Geth and Substrate.
+
+Various Talisman contributors will contribute on architecture, design, UX and testing.
+
+We have not previously applied for a grant at the Web3 Foundation.
+
+### Team Code Repos
+
+- https://github.com/TalismanSociety/talisman-web
+
+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/replghost
+- https://github.com/jonathanpdunne
+- https://github.com/0xglide
+- https://github.com/chrisling-dev
+
+### Team LinkedIn Profiles (if available)
+
+n/a
+
+## Development Status :open_book:
+
+The product is currently being developed as a separate app inside the Talisman Portal repository (https://github.com/TalismanSociety/talisman-web/tree/multisig).
+
+For a UI walkthrough for existing functionality, please see this slideshow:
+[Signet UI Walkthrough](https://docs.google.com/presentation/d/1GBEvA8QxKoYKya9iNJfODozwT1JbRP9m_I7-lk-eHEU/edit?usp=sharing)
+
+### Conversations with W3F
+We have spoken briefly to David Hawig at the W3F to introduce the project, as well as to inquire about the W3F efforts to bring credit card processing/settlement to Polkadot (ISO20022, ISO8583). We also discussed the difficulty of staking (e.g. nominating or changing validators) today using Polkadot.js, especially as complex proxy and multisig structures come into play, which has informed this proposal.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 1 month
+- **Full-Time Equivalent (FTE):** 1,5 FTE
+- **Total Costs:** 26,400 USDC
+
+Talisman uses a blended rate for grants and proposals (see previously funded initiatives [here](https://docs.google.com/document/d/192asiQ13s4EAfXFFDFgKm_W3cqBVPPPxB5VNAig7keE/edit?usp=sharing), [here](https://docs.google.com/document/d/1OlJB4a2kcgWe-TZTC4ZR5cU9ZEIk8IoC85IJv2_2rdc/edit?usp=sharing) and [here](https://docs.google.com/document/d/1KohKDEYypNw_KJING2_uHXnC0LJwUxpPHMzBRfrH68M/edit?usp=sharing)). This allows us to ensure the needed resources can be allocated to product development as well as running the company, including, as needed, to supplement the FTEs with the expertise of senior Talisman members as needed, with the goal of executing at our product quality standards. In this case, due to the value added program provided by the W3F and to show our support for the W3F mission in helping to bring new products and technologies into existence, we are applying a reduced rate.
+
+### Milestone 1 — Sign in with Substrate (SIWS) Release
+
+We have modeled our substrate login functionality (Sign in with Substrate - SIWS) on Sign in with Ethererum, and we hope this can catalyze the development of applications that build upon Substrate keypairs. We will extract the work that we have in integrating the login with Signet into an independent package that can be integrated by any team, provide website and documentation around the package, and set this on the road to becoming a standard.
+
+Authenticating a user with a Substrate key was initially developed as part of Signet, however we believe it should have a number of improvements before it can be released as a service or component ready for use by third parties:
+
+1. The version as implemented uses the JSON format with minimal payload data and only supports the server-side nonce check. We should augment this by supporting a string field that can contain information such as a welcome message or the terms of service of the dapp.
+2. We will implement both text and JSON formats for the message to be signed, for both the presentation of the message client-side, and verification of the message server-side.
+3. We will implement a field for expressing time validity/expiration of the signature, as well as the corresponding server-side check.
+
+We will also create an example “boilerplate” NextJS Dapp that integrates SIWS.
+
+On the frontend: We will prepare 3 pages to demonstrate how SIWS works can protect an app’s data:
+
+- Sign in page with SIWS button to trigger sign in flow
+- Signed in page that fetches a secret message from backend
+- Unauthorized page that does not have access to get the secret message.
+
+On the backend: We expose 3 API endpoints:
+
+- /api/nonce: To generate a nonce for user to sign on the frontend
+- /api/verify: To verify that the signed message is valid and issue a JWT
+- /api/secret: A protected endpoint that returns a secret text only if the JWT is valid
+
+The demo app will be in a configuration that enables developers to easily deploy it on Vercel.
+
+We’d like to address these improvements in the course of packaging Sign in With Substrate (SIWS) as a releasable component.
+
+- **Estimated duration:** 0,5 month
+- **FTE:** 1,5
+- **Costs:** 13,200 USD
+- **Relevant Chains:** Polkadot & Kusama
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | GPLv3 |
+| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can spin up a SIWS service and authenticate wallets, which will show how the new functionality works. |
+| **0c.** | Testing and Testing Guide | We will include documentation on verifying your SIWS integration is performing correctly. |
+| 0d. | Article | We will publish an article that explains how the service works, the work done for this grant, and direction on how to integrate SIWS into other apps |
+| 1. | JS Package: Sign in with Substrate | We will extract our Substrate sign-in service into an independent javascript package that is hostable and easily integratable into other projects |
+| 2. | Feature: Custom message | We will add the ability to specify a custom message with the payload that can, for example, function as a welcome message from the dapp or specify the terms of service for the dapp |
+| 3. | Feature: Expiration | We will add the ability for the front end to specify an expiration time for the signed message |
+| 4. | Feature: Message Formats | We will add the ability to create the message payload both as a human-readable string, in addition to the existing JSON format |
+| 5. | Feature: Message Verification | We will add the ability to verify the signed message payload in either string or JSON format |
+| 6. | Example: Integrate SIWS into Signet | We will integrate the newly created SIWS package back into Signet, replacing the initial implementation from before. This will allow Signet to function as a reference implementation for SIWS, including a front-end and back-end. |
+| 7. | Example: Create example dapp for SIWS | We will create an example “boilerplate” NextJS Dapp that integrates SIWS, including a frontend with login functionality and a backend that can verify the login and return data to logged in users. |
+| 8. | Public Docs: Sign in with Substrate | We will create a public documentation site/landing page for Sign in with Substrate, in order to catalyze adoption by other projects, as well as eventual standardization. |
+
+### Milestone 2 — Signet Staking Module Improvements re: Validator Selection & Rotation UI
+
+We would like to improve the use cases (a.k.a. modules) enabled by Signet, by enabling user-friendly validator selection. We believe this is a core use cases for organizational and institutional multisigs in Polkadot/Kusama, and would be a foundational aspect of workflows to be built out in future releases. Currently selecting or rotating validators requires complex copy and pasting actions to assemble Polkadot.js Apps extrinsics, and we believe a purpose-built front end would alleviate the pain in performing the following actions:
+
+1. Selection/rotation of validators for a nomination pool where the nomination pool controller is a pure proxy controlled by a multisig
+2. Selection/rotation of validators by the stash, where the stash is a pure proxy controlled by a multisig
+3. Selection/rotation of validators where the staking proxy is a pure proxy controlled by a multisig.
+
+- **Estimated duration:** 0,5 month
+- **FTE:** 1,7
+- **Costs:** 13,200 USD
+- **Relevant Chains:** Polkadot, Kusama, AssetHub Polkadot, AssetHub Kusama
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | GPLv3 |
+| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can spin up Signet, including the feature improvements here, which will show how the new functionality works. |
+| **0c.** | Testing and Testing Guide | We run end to end tests on the application. |
+| **0d.** | Git Deployment | We support deployment from git at this point in time, and will have instructions on this in the repository. |
+| 0e. | Article | We will publish an article that explains Signet and the work done for this grant |
+| 1. | Feature: Nom Pool Validator Selection | This feature enables an intuitive UX around viewing currently selected validators, as well as updating the validators for a nomination pool, using the nominationPools.nominate extrinsic |
+| 2. | Feature: Staking Stash Validator Selection | This will build upon the feature above to present an intuitive UX around the selection of validators for a pure proxy stash, using the staking.nominate extrinsic |
+| 3. | Feature: Staking Pure Proxy Validator Selection | This will build upon the above features to present an intuitive UX around selection of validators for a staking proxy which is a pure proxy backed by a multisig, using proxy.proxy and staking.nominate extrinsics |
+
+## Future Plans
+
+Talisman initially embarked on the Signet project in order to "scratch its own itch" and bring it's user-friendly approach to multisigs. Signet has grown into its own project focused on larger enterprises and organizations, with the mission to build out a platform that enables institutional liquidity to flow in Polkadot.
+
+For SIWS, we are interested in promoting wider adoption, as we believe that it can unlock a use cases where off-chain data is combined with on-chain data, and this may span enterprise apps/integrations or even consumer apps or games. After this grant, we will take a look at how to garner support/adoption of the technology, and collaborate with others in the ecosystem to put this on the path to becoming a standard.
+
+## Referral Program (optional) :moneybag:
+
+You can find more information about the program [here](../README.md#moneybag-referral-program).
+
+- **Referrer:** n/a
+- **Payment Address:** n/a
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** Element
+
+Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as:
+
+### Financial Support
+The Signet team is an independent team within Talisman, and receives financial, development, UI/UX and testing support as necessary.
+
+### Previous Work
+Beyond the work in the initial treasury proposal referenced below, we have made a number of significant additions:
+
+1. CSV upload for easier batched sends
+2. An initial implementation of SIWS (in progress), *Note - the addition of SIWS will remove the need to use the magic link.*
+3. An initial address book implementation (in progress)
+4. Refactoring and rearchitecting to meet upcoming needs
+
+### Previous Grants
+
+The initial version of this web app was funded by the Polkadot Treasury in February 2023.
+
+[Polkadot Spending Proposal: Business-Friendly Polkadot Multisig](https://docs.google.com/document/d/1KohKDEYypNw_KJING2_uHXnC0LJwUxpPHMzBRfrH68M/edit#heading=h.v6is2ta0txr1)
+
+>This proposal is for a business-friendly multisig frontend to lower the difficulty for teams and businesses when running their financial operations on Polkadot. Teams currently face many difficulties when trying to perform these operations, risking mistakes along the way, and leading them to choose convenience over security. We will apply Talisman’s UX and design philosophy to create improvements for standard workflows for Polkadot multisig usage (based on the current multisig pallet), and eventually integrate upgrades when improvements to the multisig pallet itself are available.
diff --git a/applications/spacewalk-bridge.md b/applications/spacewalk-bridge.md
index 60a06e95569..a18cbb63498 100644
--- a/applications/spacewalk-bridge.md
+++ b/applications/spacewalk-bridge.md
@@ -2,7 +2,8 @@
- **Team Name:** Pendulum
- **Payment Address:** [0x41826C59a853969DA6B819130E1c32A9fd7c94ba](https://etherscan.io/address/0x41826C59a853969DA6B819130E1c32A9fd7c94ba#tokentxns) (DAI)
-- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/749#issuecomment-1740030612)
## Project Overview :page_facing_up:
diff --git a/applications/ssal-commods-dex.md b/applications/ssal-commods-dex.md
new file mode 100644
index 00000000000..cdc3de728d2
--- /dev/null
+++ b/applications/ssal-commods-dex.md
@@ -0,0 +1,227 @@
+# Ssal: Ink Commodities Exchange
+- **Team Name:** Mansa Capital
+- **Product Name:** Ssal
+- **Payment Address:** 15JQDAHWTbWju9RWQfP7EQvNV9skCvm5xh69Mb5J5YMxY8Hm (USDT)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+
+## Project Overview :page_facing_up:
+
+Ssal, a blockchain-based commodities exchange, is a new version of our product called Riso, which we are now adapting to run in the Polkadot ecosystem using smart contracts. Since Riso will be mentioned frequently throughout the document, it is important to keep in mind that Ssal is a smart contract based, Substrate-specific version of Riso: Riso is a precursor to Ssal.
+
+### Overview
+
+Ssal is a blockchain-based commodities exchange platform which leverages the power of distributed ledger technology to address the challenge of transparency and trust in commodity trading while also lowering the barrier to entry for producers and consumers to enter the market. The platform will target burgeoning markets that do not have the advantage of a commodities exchange to hedge crop prices and/or cannot trade at the volumes which traditional exchanges require.
+
+We built the original version of this project, Riso, on Substrate, but realized that architecting a fully fledged parachain goes out of scope for the purposes of our application. Our team is looking for a grant to build Ssal using smart contracts running on Substrate-based chains. We believe that the technology is ready to be applied to a practical, real-world application. In short, we would like to provide the ecosystem with a user-facing, commercial product, and hopefully, by documenting our process, we can inspire others to do the same.
+
+Our team is driven by a common goal to bring more equitable and efficient financial services to the economies that need them most. We have varied professional experience in blockchain development, financial technologies, and hotel management. Our unifying factor is a strong academic background studying mathematics, data science, and computer science. We have strong ties to the region of West Africa, and a vested interest in its success and the success of web3 technologies as a whole. For us, this project is a perfect marriage between our moral ambition with our technical skills.
+
+### Project Details
+#### Mockups/designs of any UI components
+The following mockups were designed with an AMM in mind. Ssal will be implemented as a mobile app, initially with no AMM features. This means that the marketplace will consist of an organized collection of specific contracts.
+[Check out our repo!](https://github.com/AlejandroSoumah/riso-front-end)
+##### Home Page 1
+
+##### Home Page 2
+
+##### Home Page 3
+
+##### Marketplace
+
+##### Purchase Contract
+
+This page allows one to add a contract to their cart. It assumes that there is an enderlying AMM which is why one can purchase a broad category of rice at a fixed price rather than sifting through individual contracts.
+
+#### An overview of the technology stack to be used
+Frontend: React JS
+Backend: MongoDB
+Blockchain: Ink!, Rust
+
+#### Documentation of core components, protocols, architecture, etc. to be deployed
+
+**Note: Everything prior to section 2, Transaction Model, is expository and non-technical. Skip to section 2 if you want to only read technical sections.**
+
+**1.1 A Brief Overview of Commodity Exchanges**
+A commodity exchange is a marketplace where various agricultural products, precious metals, energies, and other raw materials are traded. These exchanges provide a centralized platform for market participants to buy and sell products while hedging their losses, using standardized contracts, such as options and futures.
+Standardized contracts specify the quantity, quality, and delivery terms of the underlying commodities. These contracts are traded through open-outcry or electronic trading, with prices determined by supply and demand.
+In addition to providing a platform for trading, commodity exchanges also offer services such as price information, storage facilities, and delivery services. They play a crucial role in the global economy by providing a transparent and efficient market for the exchange of commodities, enabling producers, consumers, and investors to manage their exposure to commodity price fluctuations.
+
+The current commodity trading system lacks transparency which often leads to disputes and inefficiencies in the market. Additionally, the existing system involves several intermediaries such as brokers, clearinghouses, and banks, leading to higher transaction costs and longer settlement times.
+
+**1.2 A New Model**
+Ssal aims to be a fully decentralized, global commodities exchange leveraging blockchain technology to guarantee transparency, data availability, and transaction finality. To understand why Ssal is an improvement over the status quo, one must compare its offerings to the advantages which traditional exchanges provide:
+
+1. Price transparency: Commodity exchanges provide real-time price information on traded commodities, allowing market participants to make informed decisions about buying and selling. However, existing exchanges maintain data ownership. Their order books are locked behind paywalls, and buyers are forced to trust that the exchange is reporting accurate prices. Conversely, Ssal data is transparent and available by nature since its blockchain will necessarily store the entire market history in a publicly accessible format. Additionally, clients do not need to trust the exchange itself, they need only trust the mathematics which govern its functions. Modern exchanges are intermediaries, they own their client’s trades. Ssal provides an upgradeable framework for the free market to govern its own transactions.
+
+2. Price discovery: The exchange provides a platform for buyers and sellers to come together and determine the market-clearing price of the commodity based on supply and demand. Where Ssal improves on this model is by removing trading minimums. Restrictively high minimums, in turn, restrict true price discovery, not to mention, make it impossible for small-scale, local trade to experience the benefits of commodity hedging. Ssal would provide a platform which allows for more complex market interactions where several market niches can form around a single product. Geographically localized markets with relatively small transactions could form economic sub-groups which distinguish themselves from the macro trends which, by and large, govern the social perception of a given commodity.
+
+3. Risk management: Commodity exchanges offer standardized futures and options contracts, which allow market participants to manage their price risk exposure and hedge against unfavorable price movements. Ssal proposes a less restrictive transactional model which allows for broader financial expression. Instead of restricting contracts to futures and options Ssal defines a contract as a set of upgradeable parameters which can be tuned to the producer’s financial needs (covered in section 3). This open ended financial model allows for a more thorough hedging process which better serves buyers and sellers’ needs.
+
+4. Liquidity: The exchange provides a central marketplace for trading, which enhances liquidity and reduces transaction costs, making it easier for buyers and sellers to find counterparties to trade with. Ssal takes this a step further by removing intermediaries and minimums driving liquidity further up and transaction costs down.
+
+5. Quality assurance: Commodity exchanges ensure that the commodities traded meet certain quality standards, which reduces the risk of default and ensures that buyers receive the expected quality of the commodity. This model, functional as it may be, is restrictive. Products must all flow through the same center before they can be shipped off to their final destinations. This is both inefficient and stifling for smaller, localized economies. Ssal proposes a solution in which local businesses which specialize in quality assurance become partners. This allows for trade to happen any time from anywhere, reducing transportation costs. It also stimulates local economies and helps local supply chains grow.
+
+6. Storage and delivery: Commodity exchanges offer storage facilities and delivery services, which enable market participants to take physical delivery of the commodity if required. Riso takes a different approach: the best commodity exchange will never be the best transportation company or storage facility, because they are different products which face very different sets of challenges. Instead, much like the quality assurance issue, Ssal connects its clients with local transportation companies, which can much better serve their communities. This, in turn, supports small businesses in the underlying economy.
+
+By lowering barriers to entry, Ssal can bring the benefits of commodities trading to untapped markets; it can bring improvements to existing markets; and can promote a more equitable and globalized economy.
+
+Ssal offers a promising solution to the challenges facing the current commodity trading system. The platform will improve transparency, reduce transaction costs, and enhance trust in the market. By eliminating intermediaries, the platform will enable buyers and sellers to transact directly, leading to faster settlements and improved efficiency.
+
+Our mission with Ssal is to create a better logistic-financial layer which will help economies retain the profit they generate and flourish.
+
+**1.3 Design Philosophy**
+Ssal is intended to be the best global framework for trading commodities. For a novel product to become the best at what it does it needs to specialize in accordance with a clear vision and offload as much unrelated labor as possible. This is why Ssal will be built such that it only fulfills its core functions, but makes it easy for users to plug in other specialized products to fill in the gaps. By serving only its core functions and leaving the rest to other specialized teams Ssal creates a platform for other companies to thrive. It would allow each component of the ecosystem to perform its function to the best of its ability. Ssal will never be the best storage facility, it will never be the best messaging app, but Ssal will make it easy for buyers and sellers to connect themselves with the solutions that are going to best serve their needs. Ssal serves to transact and record transaction history while allowing communication channels, delivery services, and legal systems to perform at their best where necessary.
+
+**2 Transaction Model**
+The central problem for a decentralized commodities exchange is making sure that physical products reliably change hands. Ssal's proposed solution is called the open-lockup model.
+
+The open-lockup model is a method for designing standardized commodity contracts which lets the seller designate custom functionality for their contracts while protecting buyers’ funds from fraudulent transactions. It works by delineating a set of upgradeable contract presets:
+1. Cost of purchasing the contract.
+2. The price per unit of volume for the commodity.
+3. The volume of product to be traded.
+4. Choosing to give the right to purchase or the obligation to purchase a chosen volume of product.
+5. The finality date for the contract. The date by which a physical product legally changes hands (note that this does not mean that the physical product was transported, it simply means that on-chain records will indicate a change in ownership of the supposed product).
+6. Designating which party (the buyer or the seller) is responsible for transportation and its related costs.
+
+This open model allows for markets which better serve the niche requirements of commodity producers and purchasers. It creates an upgradeable set of conventions which allow the market to optimize itself.
+The lockup model adds a layer of security for buyers. It freezes the buyer's funds until a contract’s finality date, at which point, the buyer will either verify that the physical product exists, is of good quality, and is changing hands, or they deny the quality/existence of the physical product and their funds are returned. For all transactions, complete or incomplete, there is an on-chain record of the transaction, so either party can use such information to take legal action against the other if they feel compelled to do so. A blockchain provides the ideal paper-trail to build a solid case and would disincentivize fraudulent activity.
+
+The open-lockup model provides an open-ended model for creating commodity contracts which can act as options, futures, spot deals, and any permutation of the three. It also provides an economic model which disincentivizes fraudulent actors from misappropriating the product.
+
+In future iterations of this project, we intend on adding a governance system so that transaction participants can call a trial when they have a dispute. The trial would use a random sample of jurors presented with each participant's case to decide whether the locked funds should be sent back to the buyer or transferred to the seller.
+
+**3 Implementation**
+Ssal will start as a very simple application utilizing three core functions:
+1. Create contract: a producer lists a contract they want to sell. In storage this is represented by a struct containing an index for the contract, the price of the contract itself, the price per unit of product being sold, the seller’s account id, the buyer’s account id (initialized with a default value), and the finality date of the contract (stored as a block number). Each contract struct is written to a storage map for quick access later.
+2. Purchase contract: the buyer’s account id is written to the respective contract struct and the amount of funds designated by the price of the contract are transferred from the buyer to the seller.
+3. Finalize contract: on the finality date (finality block) the buyer's funds are locked up in an intermediary account. Once the buyer confirms that they have received their product those funds are transferred from the intermediary to the seller.
+
+In future iterations, decentralized governance features will be added to handle commercial disputes. A system will be implemented where registered parties will vote in a series of trials to determine whether the funds locked in the intermediary will be transferred back to the seller or the buyer’s account. Additionally, we will add a framework for creating customizable AMMs. Each AMM will subscribe to one contract standard and a body of trusted quality assurance companies backing the given AMM. This system would improve transaction throughput and allow for a more seamless user experience on the frontend.
+
+
+#### PoC/MVP or other relevant prior work or research on the topic
+We used a blockchain startup competition held by [Franklin Templeton](https://www.franklintempleton.com/) to prove out our initial concept, Riso. Below we have attached github links containing relevant code and files we produced in the first iteration of this project, Riso.
+
+Mock frontend https://github.com/AlejandroSoumah/riso-front-end
+Concept substrate chain https://github.com/MatteoPerona/Riso
+Relevant files https://github.com/MatteoPerona/riso-concept-files
+
+
+#### What your project is _not_ or will _not_ provide or implement
+Our project is not and does not intend to be a parachain/developer ecosystem. It is an end-user application.
+
+### Ecosystem Fit
+#### Where and how does your project fit into the ecosystem?
+The W3F has expressed an interest in funding projects which would expand the use case for ink Smart Contracts. Ssal would introduce a novel set of smart contracts geared towards commodities trading which could be repurposed to fill a wide range of commercial niches.
+
+#### Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?
+Our target audience is, first and foremost, our own user base. Our goal is to bring the most cutting edge financial tools to agricultural supply chains in West Africa. That being said, Ssal's source code would be open source, and we strive to build technologies that can inspire other developers to expand on what we've created for the world of decentralized commerce.
+
+
+#### What need(s) does your project meet?
+By lowering barriers to entry, Riso can bring the benefits of commodities trading to untapped markets; it can bring improvements to existing markets; and can promote a more equitable and globalized economy.
+Riso offers a promising solution to the challenges facing the current commodity trading system. The platform will improve transparency, reduce transaction costs, and enhance trust in the market. By eliminating intermediaries, the platform will enable buyers and sellers to transact directly, leading to faster settlements and improved efficiency.
+Our mission with Riso is to create a better logistic-financial layer which will help economies retain the profit they generate and flourish.
+
+
+#### Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?
+The main other project in the ecosystem tackling commodities is Watr. That being said, this project has wildly different goals and implications for the ecosystem. They are focused on building a, "blockchain platform that is open to everyone who wants to build". They take a birds eye view when tackling decentralized commodities, while Ssal focuses on one specific problem in one specific sector. The nature of both projects is in fact symbiotic since the smart contracts developed for Ssal may be deployed to Watr which would further their ambitions.
+
+## Team :busts_in_silhouette:
+### Team members
+- Matteo Perona (PBA1 Alum, Fullstack Dev @ Parachains Development Inc., BS Data Science UCSD)
+ - Ssal: Leads development of core technology
+ - Graduated from the first wave of the Polkadot Blockchain Academy
+ - Has been working in the ecosystem ever since with Parachains Development Inc.
+ - Projects: FlowStream (previously Sumi), Mission Control
+ - Specialties: Cryptography, SWE, Data Science/Engineering
+- Alejandro Soumah (Quant @ Goldman Sachs, BA Math & CS UCSD)
+ - Ssal: Manages correspondence and implementation of technology
+ - Worked as a Quantitative Analyst at Goldman Sachs
+ - Specialties: Financial Systems, SWE, Stochastic Processes
+- Taerim Choi (HR Coordinator @ Hyatt Regency, Lead Web Dev @ DP Circle, BA Math & CS UCSD)
+ - Ssal: Handles UI/UX and operational logistics
+ - Lead Web Development at a startup called DP Circle
+ - Worked as an HR Coordinator at Hyatt Regency in Seattle
+ - Specialties: Operations Logic, SWE, Legal
+
+### Contact
+- **Contact Name:** Matteo Perona
+- **Contact Email:** matteroperona@mansacaptital.us
+- **Website:** https://mansacapital.us/
+
+### Legal Structure
+- **Registered Address:** 2514 Highland Ave, Altadena, CA, 91001
+- **Registered Legal Entity:** Mansa Capital LLC
+
+### Team's experience
+As was mentioned before, our team has individual experience in blockchain development, fintech, and corporate management. That being said, we also have plenty of experience working together on the non-profit we founded called [COMPASS](http://www.compassinstitution.com/).
+
+At our non profit, we carry out mathematics/computer science projects geared towards social good.
+
+In one of our projects, we built a clustering algorithm which takes yelp reviews for a given business as input and creates clusters which relevantly partition semantic patterns in the sample space. We will eventually use our model to survey the homeless population of San Diego and cluster their responses to our questions in order to better understand the general trends within the entire population. We will present our findings to the city government by the end of the year and publish a paper.
+
+All this to say we have a few years worth of experience managing large projects together and building effective teams.
+
+### Team Code Repos
+Original Riso Blockchain https://github.com/MatteoPerona/Riso
+Mock Frontend for Riso https://github.com/AlejandroSoumah/riso-front-end
+
+Matteo Perona https://github.com/MatteoPerona
+Alejandro Soumah https://github.com/AlejandroSoumah
+Taerim Choi https://github.com/cherrytoi
+
+### Team LinkedIn Profiles (if available)
+Matteo Perona https://www.linkedin.com/in/matteo-perona/
+Alejandro Soumah https://www.linkedin.com/in/alejandro-soumah/
+Taerim Choi https://www.linkedin.com/in/taerim-choi/
+
+
+## Development Status :open_book:
+The following files, also attached above, are from the competition we participated in to test out our idea before looking for a grant.
+
+Mock Frontend https://github.com/AlejandroSoumah/riso-front-end
+Original Blockchain Concept https://github.com/MatteoPerona/Riso
+Files from the competition https://github.com/MatteoPerona/riso-concept-files
+
+The last link attached contains our original concept white paper along with a one-pager and a pitch deck covering our original idea. As was mentioned before, we fleshed out this idea while working in a startup competition, so the materials are less technical and more business minded. The whitepaper was from an iteration of the app for which we built a rudimentary substrate based chain with a commodities pallet. In our next iteration we would like to take the functionality we built into that pallet and reduce it to a set of smart contracts.
+
+Other resources we used while researching:
+The Watr Whitepaper https://watr.org/wp-content/uploads/2023/06/Watr-Whitepaper-1.pdf
+ADB Sustainable Development Working Paper Series https://www.adb.org/sites/default/files/publication/29972/adb-wp-25-commodities-exchange.pdf
+
+## Development Roadmap :nut_and_bolt:
+### Overview
+- **Total Estimated Duration:** 2 Months
+- **Full-Time Equivalent (FTE):** 2.5
+- **Total Costs:** 10,000 USD
+
+### Milestone 1 Example — Basic Smart Contracts and UI
+
+- **Estimated duration:** 2 months
+- **FTE:** 2,5
+- **Costs:** 10,000 USD
+
+| Number | Deliverable | Specification |
+| -----: | ----------- | ------------- |
+| **0a.** | License | GPLv3 |
+| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** in our web documentation that explains how a user can interact with our smart contracts through CLI. |
+| **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** covering everything the team has built and learned. It will act as a compilation of our learnings trying to apply our blockchain application.|
+| 1. | Smart Contracts | We will write the requisite ink! smart contracts to create, buy, and sell commodities contracts. **Storage:** The contract storage struct will contain a packed mapping of balances for users on the network and an unpacked mapping containing vecs storing each commodity contract’s data. Additionally, it will store a contract count (u64) and an account id representing an intermediary account used to lock up funds from the buyer after the finality date has passed. **Functions:** The exposed functions will include, buy, create, and finalize. Buy takes a contract index and sender. It transfers the requisite funds from the buyer (sender) to the seller specified on the contract vec in storage. Then, it writes the sender’s account id to the storage vec for the contract. Create takes in all the required commodity contract specifications and stores the data as a vec in the unpacked mapping mentioned above. Finalize can only be called by a buyer for an active contract which they have purchased. It transfers the final price of the contract from the buyer’s account to the seller’s account. In addition to these three functions, another function, lockup, will call at the beginning of each new block. It finds all contracts whose finality date corresponds with the current block and transfers the respective buyer’s funds to the intermediary account. If finalize is called after lockup was called the funds are transferred from the lockup account instead of the buyer’s.|
+| 2. | Frontend | We will deliver a simple user interface tailored for mobile devices using React Native. At this stage, it will remain disconnected from any blockchain functions. **Components:** (1) Marketplace view, where users filter through individual contracts displayed as interactable cards. It will also include a menu button which opens the togglable sidebar menu. (2) The menu contains the user’s profile button, contract creation button, and the marketplace button. (3) The purchase view pops up when a contract card is tapped. It displays all contract specifications and allows the user to purchase the given contract. (4) The profile view displays the username, email, and public key for the user along with any active contracts they have bought or sold. (5) The contract creation view opens when the contract creation button is clicked from the menu. This view contains input fields for each contract specification. When finished the user taps a button at the bottom to publish their contract.|
+
+
+## Future Plans
+- Improve infrastructures for continuous integration and maintenance
+- Add a customizable AMM to make buying and selling contracts easier for clients
+- Add a governance system to resolve disputes between contract participants
+
+## Referral Program (optional) :moneybag:
+- **Referrer:** Brian Teague
+- **Payment Address:** 5ComeRmB78wG7C3Xaph7o7GEJzLBAL9wfXrVUyFj9DS4SqCU (USDT)
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** personal recommendation: PBA team, Marta Carlaslake
diff --git a/applications/subsmt.md b/applications/subsmt.md
new file mode 100644
index 00000000000..553b6a5bf0e
--- /dev/null
+++ b/applications/subsmt.md
@@ -0,0 +1,155 @@
+# SubSMT
+
+- **Team Name:** farcloud-labs
+- **Payment Address:** 0xd08aD17A0336b52099ae54C81E668aeBfB3c968e(USDC)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1
+
+## Project Overview :page_facing_up:
+On-chain resources are precious, and more and more teams, especially L2,
+need to put data and calculations off-chain, and Merkel trees are used more frequently.
+Sparse Merkle trees are widely used in blockchains, and have been used hundreds of thousands of times in the Ethereum community.
+Polkadot uses the rust language as its development language, and the implementation of sparse Merkel trees currently lacks a unified solution.
+Especially in substrate and ink, if there is an implementation template for sparse Merkle trees,
+it will greatly save the community's development time and avoid repeated development.
+This project will do just that.
+### Overview
+
+- tags `rust, substrate, ink, sparse-merkle-tree, rocksdb, paritydb`
+- Provides a substrate-based pallet, an ink-based smart contract and an off-chain data backend.
+- Sparse Merkle trees are widely used in blockchain technology solutions and can be used to store data and verify data integrity,
+reducing the computing and storage pressure of the chain. We noticed that there is currently only the MMT solution in substrate,
+and sparse Merkle trees should also be provided to allow community developers to have more choices and avoid repeated development.
+The sparse Merkle tree follows a strict and complete binary path, which can better obtain the root in advance when the data has not been updated
+(This is very useful to prevent off-chain data inconsistency after the blockchain transaction is rolled back),
+and verify the non-existence of data, and the structure of the Merkle tree rarely changes when data is updated, and related operations are all log(n), etc.
+It has almost perfect balance and stability, allowing more possibilities in algorithms and providing more functions.
+It is a Merkle tree solution that is well worth adopting.
+
+### Project Details
+#### technology stack
+language: `rust, substrate, ink`.
+1. Sparse Merkle tree and data backend implemented in rust.
+2. Pallet for verifying sparse Merkle root.
+3. Verify sparse Merkle tree root, ink contract.
+
+#### What your project is *not* or will *not* provide or implement
+For the specific off-chain implementation of the sparse Merkle tree,
+we will not reinvent the wheel and directly use [https://github.com/nervosnetwork/sparse-merkle-tree](https://github.com/nervosnetwork/sparse-merkle-tree),
+but we may make necessary changes to it. such as in smart contracts,
+resources are precious, so use the algorithm that consumes the least Gas as much as possible, and for example, change some of its code to be compatible with substrate.
+Here’s to thanking them for their great work.
+On-chain, we use the most intuitive and gas-saving verification method to meet the gas-saving needs of all teams.
+
+In orbiter's Ethereum smart contract, we originally planned to use [https://github.com/nervosnetwork/sparse-merkle-tree](https://github.com/nervosnetwork/sparse-merkle-tree) directly,
+but later found that there are much serialization and verification algorithm levels that do not meet our needs to consume the least Gas.
+This is also the reason why we provide this project for the Polkadot community to use. This will prevent community developers from having to do something like this repeatedly.
+
+
+### Ecosystem Fit
+
+SubSMT serves projects that require off-chain storage and then on-chain verification of data integrity.
+This project is suitable for teams that want to use sparse Merkel trees and is also the best choice.
+In the Polkadot ecosystem, the only implementation of Merkle tree is MMT. This is an urgent need for sparse Merkle trees with a large user base.
+With this unified solution, community tools are further improved and the development ecosystem is further prosperous,
+which greatly helps developers save more time.
+
+Our goal is to create a Polkadot eco-friendly sparse Merkle tree solution based on rust, substrate and ink, not other languages. Developing
+based on rust will be beneficial to the use of ecological projects because it has greater compatibility.
+And many zero-knowledge proofs use languages similar to rust or use rust directly, which can be used by them in the future.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+* YanOctavian
+* octavei
+
+### Contact
+
+- **Contact Name:** octavei
+- **Contact Email:** octavei@proton.me
+
+### Legal Structure
+
+- **Registered Address:** No. 6, Jiusi Team, Renlian Village, Laren Town, Du'an Yao Autonomous County, Guangxi, China.
+- **Registered Legal Entity:** N/A
+
+### Team's experience
+* `YanOctavian` worked in the Ethereum L2 cross-chain bridge Orbiter team, responsible for decentralized sequencer development and decentralized client submitter development. He has 3 years of rust development experience and 5 years of blockchain smart contract development experience.
+* `octavei` 4 years experience in substrate development. Familiar with Ethereum and EOS smart contracts. Have done many blockchain projects.
+> There are also some people whose identities are not disclosed and who do not participate in development, but will provide basic help, such as contract security reviews and technical opinions. At the same time, they will not benefit from the grant of this project. They all have extensive experience in blockchain contracts. Thank them here.
+
+### Team Code Repos
+
+- https://github.com/farcloud-labs/submitter
+- https://github.com/farcloud-labs/subsmt
+- https://github.com/farcloud-labs/sparse-merkle-tree
+
+***
+- https://github.com/YanOctavian
+- https://github.com/Octavei
+
+
+## Development Status :open_book:
+
+- https://github.com/farcloud-labs/subsmt
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 2 months
+- **Full-Time Equivalent (FTE):** 3 FTE
+- **Total Costs:** 10000 USD
+
+### Milestone 1 - SMT pallet, SMT ink smart contract, and backend base on rocksdb.
+
+- **Estimated duration:** 1 month
+- **FTE:** 2
+- **Costs:** 7,000 USD
+
+> :exclamation: **The default deliverables 0a-0d below are mandatory for all milestones**, and deliverable 0e at least for the last one.
+
+| 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 (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. |
+| **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. |
+| 1. | rust crate: SMT-api | Basic APIs based on rocksdb, such as new verify_root method, update, insert and get_futrue_root, etc. |
+| 2. | Substrate module: SMT | We will create a Substrate module that will verify Merkle root. |
+| 3. | Smart contracts(ink): SMT | We will deliver a set of ink! smart contracts that will will verify Merkle root.
+| 4. | backend | backend, used for permanent storage(based on rocksdb) of off-chain data and provision of rpc services. |
+| 5. | network | A basic network with SMT pallet and contract pallet for testing smart contracts and SMT pallet functions. |
+> It also includes some changes to the hash algorithm and the selection of data serialization and deserialization algorithms, as well as the testing of these parts, which do not need to be included in the milestone work because some of them have been completed before.
+
+### Milestone 2 - backend base on parity-db and common backend.
+- **Estimated Duration:** 1 month
+- **FTE:** 1
+- **Costs:** 3,000 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 (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. |
+| **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 How SubSMT works |
+| 1. | rust crate: smt-paritydb-store | Sparse merkle tree parity-db store implementation |
+| 2. | paritydb-store-api | Basic APIs based on smt-paritydb-store, such as new verify_root method, update, insert and get_futrue_root, etc. |
+| 3. | common-backend | A backend compatible with smt-rocksdb-store and smt-paritydb-store |
+
+## Future Plans
+- On-chain implementation of more functions besides verifying Merkel root.
+- Provide more permanent storage solutions off-chain, not just rocksdb and parity-db.
+- Compatible with EVM, allowing it to be used in smart contracts on parallel chains such as moonbeam.
+
+## Referral Program (optional) :moneybag:
+
+- **Referrer:** [JimYam](https://github.com/w3f/Grants-Program/pull/1050)
+- **Payment Address:** 0x2c738f52A6BC738d556095A79b9fc49359fE0159(USDT)
+
+## Additional Information :heavy_plus_sign:
+
+**How did you hear about the Grants Program?** personal recommendation.
+
diff --git a/applications/tracking_chain.md b/applications/tracking_chain.md
index 64182b5403a..f1d05c0719c 100644
--- a/applications/tracking_chain.md
+++ b/applications/tracking_chain.md
@@ -46,9 +46,9 @@ The application will handle all the necessary infrastructure setup for transacti
The project will consist of 9 microservices, each with a well-defined task.
-
+
-
+
1. Triage API:
- Purpose: Receives tracking requests, consults the registry, and associates a destination smart contract with each request based on a Profile.
@@ -80,8 +80,6 @@ The project will consist of 9 microservices, each with a well-defined task.
9. Tx Monitor Worker:
- Purpose: Monitor the status of transactions to proceed with any automatic actions or to launch alerts in the event of transactions that cannot be managed automatically.
-
-
### **Overview of the technology stack to be used**
We are planning on using a combination of blockchain technology, cloud services, and front-end development tools to build a performant, secure, and user-friendly platform.
@@ -140,7 +138,7 @@ I'm working on a project for a censorship-resistant decentralized video platform
- **Total Estimated Duration:** 6.5 month
- **Full-Time Equivalent (FTE):** 1
-- **Total Costs:** 16.500 USD
+- **Total Costs:** 16.200 USD
### Milestone 1 — Basic functionality
@@ -205,9 +203,9 @@ I'm working on a project for a censorship-resistant decentralized video platform
### Milestone 4 — Ink Generation Call Improvement
-- **Estimated duration:** 1 month
+- **Estimated duration:** 3 weeks
- **FTE:** 1
-- **Costs:** 2.000 USD
+- **Costs:** 1.700 USD
| Number | Deliverable | Specification |
@@ -218,11 +216,10 @@ I'm working on a project for a censorship-resistant decentralized video platform
| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. |
| 0e. | Article | We will publish an **article**/workshop that explains how to use. |
| 1. | Tx Generator Worker | Improvement to wait for the transaction to be finalized in order to skip the "Tx Watcher Phase" (this mode will be an option present in the configuration) it's will also allow for better support for chains that don't have access to subscans. To achieve this we will listen via socket in order to wait for the finalization of the generated Tx |
-| 2. | Frontend Registry | Improvement that allows you to view not only the data present in the Registry but also to take directly from the data saved in the onchain smart contract |
## Future Plans
-- Pres ent the demo to customers and onboard our first major customer.
+- Present the demo to customers and onboard our first major customer.
- Continue meetings with customers interested in entering the web3 and onboard other customers.
- Participate in events to be able to demonstrate how our demo works, also showing the portfolio of customers who have already chosen to use it.
- Integration DID with Kilt
@@ -254,5 +251,3 @@ I'm working on a project for a censorship-resistant decentralized video platform
- No, all "Future Plans" will be covered by new clients or carried forward by me.
3. Have you applied for other grants so far?
- No
-
-
diff --git a/applications/tux0.md b/applications/tux0.md
new file mode 100644
index 00000000000..f131657ea7a
--- /dev/null
+++ b/applications/tux0.md
@@ -0,0 +1,242 @@
+# Tux0
+
+- **Team Name:** Libeccio Labs
+- **Payment Address:** 12poSUQPtcF1HUPQGY3zZu2P8emuW9YnsPduA4XG3oCEfJVp (USDT on Asset Hub)
+- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 🐤
+
+## Project Overview :page_facing_up:
+
+A [Tuxedo](https://github.com/Off-Narrative-Labs/Tuxedo) piece that leverages zero-knowledge proofs to manage a private token.
+
+### Overview
+Zero-knowledge proofs are revolutionizing the way we interact with the blockchain. They can be used to create new types of applications that are more private and secure.
+We are particularly interested in finding a proving system which does not require a trusted setup, and is good enough to be used in a Substrate runtime.
+Truth is zero knowledge primitives on parachains as host functions are still far, since it is a long and tedious path to decide, implement, test, and bring them on the relay chain, which involves Parity and the Polkadot Fellowship.
+
+Every developer in the Substrate ecosystem can benefit from this research. If we are successful in figuring out a fast and efficient zk protocol for Substrate runtimes, it will open up a whole new range of possibilities for runtime developers, particularly for parachains.
+
+A DAP (decentralized anonymous payment) is the simplest, yet useful, implementation of zero-knowledge proofs in blockchain we could think of, because it only needs to prove that the sender has the private key corresponding to the output UTXO and that the transaction is valid.
+
+We naturally chose to build on Tuxedo because it is designed to make it easy to develop UTXO-based blockchains, which DAPs typically are. For example, Manta Network implemented UTXOs inside a FRAME pallet for the same purpose, which is not ideal.
+We believe that an UTXO-based alternative to FRAME was needed, to provide developers with more choices and flexibility, leading to innovation and experimentation, which can benefit the entire ecosystem.
+As a consequence of this choice, this project will prove that Tuxedo is ready for people to write their own runtimes, and hopefully soon their parachains as well.
+However, the objective of this project is not to develop a production-ready module, but to conduct a research and showcase our results to the Substrate community as a whole.
+
+### Project Details
+
+#### Research phase
+
+The first part of the project will involve a research on zero knowledge protocols, with the objective of finding out a protocol that can potentially be used in a parachain runtime. We're particularly interested in non-interactive protocols that don't require a trusted setup, use succinct proofs, are fast to verify.
+Some potential candidates are:
+- [Halo2](https://github.com/zcash/halo2/), used by Zcash in its orchard protocol;
+- [Plonky2](https://github.com/0xPolygonZero/plonky2), developed by Polygon Zero;
+- [Kimchi](https://github.com/o1-labs/proof-systems), by O(1) Labs, used by the Mina Protocol.
+
+The zero knowledge protocol used in the second phase will be chosen based on this research's results. The factors that will be considered are, by importance:
+- verification performance and proof size;
+- proof construction performance;
+- security, if the library is production-ready;
+- ease of use, for example high level languages to write circuits.
+
+Proof construction performance and proof size will be measured by running the construction function on a set of pre-generated inputs, and measuring the average time it takes to construct each proof. The prover will be tested in both native and WASM, as the wallet is currently only available as a native binary, but we think it would make sense to have a library that can be used in-browser as well.
+
+Verification performance will be measured by running the verification function on the previously generated proofs, and measuring the average time it takes to verify each proof. The verifier will need to be compiled to WASM, since it will be used in a Substrate runtime.
+The execution times of some real-world FRAME extrinsics will be measured and included as well, as we hope to find a protocol with comparable execution times.
+
+We are aware that the results might not be as good as expected. If we fail to identify a protocol that can be used in a Substrate runtime, then we would still proceed with developing the final product, using custom host functions.
+However, since some of these protocols are already used in other blockchains, we're confident this phase will be a success.
+
+###### Benchmarking program architecture
+
+There will be a sovereign trait to be implemented for each protocol one wants to benchmark.
+One can also extend the trait to add more test cases to the benchmarking program.
+Something along the lines of:
+```rust
+pub type Proof = Vec;
+
+pub trait Protocol {
+ /// Build a proof for the sum of two numbers
+ fn sum_build_proof(a: i64, b: i64, sum: i64) -> Proof;
+ /// Verify a proof for the sum of two numbers
+ fn sum_verify_proof(proof: Proof) -> bool;
+
+ /// Build a proof for a Sudoku
+ fn sudoku_build_proof(sudoku: Sudoku) -> Proof;
+ /// Verify a proof for a Sudoku
+ fn sudoku_verify_proof(proof: Proof) -> bool;
+
+ // ... other tests ...
+
+ pub fn run_benchmarks() -> Vec {
+ let sum_proof = Self::sum_build_proof(2, 1, 3);
+ // ... run all the benchmarks ...
+ }
+}
+```
+We will implement a `run_benchmarks` method for every type that implements the Protocol trait, and we will provide a blanket implementation of Protocol for tuple of types that implements Protocol.
+```rust
+type Protocols = (Halo2, Plonky2, Kimchi);
+
+fn main() {
+ let benchmarking_results = Protocols.run_benchmarks();
+ // ... export the results ...
+}
+```
+With this system, integrating new protocols will be as easy as implementing the Protocol trait for them, and adding a new item to the Protocols type.
+
+#### Development phase
+
+The final product will be a Tuxedo piece, written in Rust, which can be used in any Tuxedo runtime for private token transactions. The code will be stored in a public GitHub repository, along with an example on how to use it in a Tuxedo runtime. The documentation will be generated from Rustdocs and hosted on GitHub pages.
+We will also develop an extension for Tuxedo's wallet, to be able to retrieve the balance for a certain address, build zero knowledge proofs and send transactions.
+We will write unit tests for all of the Tuxedo primitives we develop for Tux0 to ensure that they are functionally correct, along with integration tests to show that the Tux0 wallet can successfully create and verify transactions against a template runtime.
+
+The basic primitives behind the protocol we designed for Tux0 are:
+- **Coin**, a simple public currency, managed by the [Money piece](https://off-narrative-labs.github.io/Tuxedo/money/index.html). Each UTXO has a certain monetary value, and optionally an owner.
+Wallets need to check all the transactions, to see if any produced UTXO is owned by a certain address they manage. Using the same process, any external entity can easily figure out the balance and transaction history for any public key.
+- **DAP Coin**, similar to Coin, but it is stored on-chain as a H256, encrypted using the owner’s public key. Each UTXO has a private monetary value, an owner, and other parameters needed for proving its ownership and uniqueness.
+Wallets will need to check all the transactions to see if any produced DAP Coin can be decrypted and decoded. However, external entities will not be able to understand the senders, recipients and values of any transaction, ensuring privacy.
+- **Transfer function**, the only transaction the Tux0 piece will allow, which can consume and produce Coin or DAP Coin indiscriminately. As a consequence, users can freely convert Coin to DAP Coin and vice versa.
+Each DAP Coin in input requires a zero knowledge proof to demonstrate the sender has the right to consume it, without revealing its identity.
+Another zero knowledge proof is needed to prove that the operation is valid, because the sum of the outputs is less or equal to the sum of the inputs, without revealing any of these numbers.
+Due to constraints imposed by the chosen proving system, this function will have a limited amount of inputs and outputs.
+
+We can't guarantee for the project's security, since its purpose is to demonstrate the use of the chosen zero knowledge protocol, not to write a production-ready module. For that, the protocol should be thoroughly reviewed by experts, and the libraries and piece should be subject to security audits.
+
+### Ecosystem Fit
+
+Our research will be useful to the Substrate community because it will help to identify zero-knowledge protocols that are suitable for use in Substrate runtimes.
+This could enable Parachain developers to use zero-knowledge proofs for any use-case they want, without needing to wait for primitives to be added to the Relay Chain.
+
+After a proper security audit, Tux0 would be a valuable tool for developers who want to build privacy-preserving dapps on the Polkadot/Substrate/Kusama ecosystem. It would also be useful to users who want to be able to send and receive tokens privately.
+Moreover, Tux0 would demonstrate that Tuxedo is ready for developers to build their custom logic on top of it, and hopefully to be able to use it in production soon.
+
+Even if fundamentally different, the protocol we designed for Tux0 is inspired by the Zerocash protocol, which uses zero knowledge proofs for private transactions.
+An example of zero knowledge proofs used for private transactions can be found in Manta Network, where the protocol used requires a trusted setup. Moreover, their private coin is a simulation of UTXOs written inside a FRAME pallet, while Tuxedo allows native UTXOs in a Substrate runtime, and we are sure that our transactions costs will be fundamentally lower.
+
+## Team :busts_in_silhouette:
+
+### Team members
+
+- Matteo Muraca
+- Alberto Perrella
+
+Advisors:
+- Joshy Orndorff
+
+### Contact
+
+- **Contact Name:** Matteo Muraca
+- **Contact Email:** muraca.matteo@icloud.com
+
+### Legal Structure
+
+- **Registered Address:** N/A
+- **Registered Legal Entity:** N/A
+
+### Team's experience
+
+Matteo and Alberto were the first hires at NFT Chain, and worked there until its termination of business.
+Matteo successfully graduated at the second cohort of the Polkadot Blockchain Academy in Buenos Aires, after which he started contributing to the Polkadot SDK, and lately to Tuxedo as well. At NFT Chain, he was one of the core developers for a parachain to handle custom non-fungible assets with formal constraints.
+Alberto holds a Master's Degree in Mathematics at ETH Zurich. At NFT Chain, along his core team duties, he was responsible for prototyping a protocol that leverages zero knowledge proofs to facilitate the verification of formal constraints on-chain.
+
+Unfortunately, all the work done at NFT Chain is private, and we're legally obliged to not share it.
+However, we presented some working prototypes at Sub0 2022, and the project has been accepted as part of the Substrate Builders Program.
+
+
+---
+
+Joshy Orndorff is one of the main contributors to Tuxedo. He's entered the Substrate ecosystem in 2019, and among all things he also taught the Polkadot Blockchain Academy in all three cohorts: Cambridge, Buenos Aires, and Berkeley.
+He will not be directly involved in the development of this project, but he will be available for advice and guidance, mostly on the Tuxedo side.
+
+### Team GitHub Profiles
+
+- https://github.com/muraca
+- https://github.com/Gorzorg
+
+The eventual code and documentation will be published in the Libeccio Labs GitHub organization:
+- https://github.com/LibeccioLabs
+
+### Team LinkedIn Profiles
+
+- https://www.linkedin.com/in/matteo-muraca/
+- https://www.linkedin.com/in/alberto-perrella-2522bb1a2/
+
+
+## Development Status :open_book:
+
+We have currently identified some zero knowledge protocols which might become candidates for the research part.
+We also started sketching out some code for a Tuxedo piece, but nothing worth mentioning.
+
+## Development Roadmap :nut_and_bolt:
+
+### Overview
+
+- **Total Estimated Duration:** 20 weeks
+- **Full-Time Equivalent (FTE):** 1.5 FTE
+- **Total Costs:** 30,000 USD
+
+### Milestone 1 — Research phase, part 1
+
+- **Estimated duration:** 8 weeks
+- **FTE:** 1.5
+- **Costs:** 12,000 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 run the proofs. |
+| **0c.** | Testing and Testing Guide | The circuits will be tested with valid and invalid witness values. 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. | Demo proofs | We will implement 2 zero knowledge proofs ([_Sudoku_](https://en.wikipedia.org/wiki/Sudoku) and [_Factorial_](https://en.wikipedia.org/wiki/Factorial)) for 2 protocols. These proofs will be later integrated in the benchmarking program defined in milestone 2. |
+| 2. | Articles on protocols | We will publish two **articles** on our GitHub blog, one for each protocol, documenting our development journey, highliting pros and cons, along with general comments about usability and suggestions for developers who want to use them. |
+
+### Milestone 2 — Research phase, part 2
+
+- **Estimated duration:** 6 weeks
+- **FTE:** 1.5
+- **Costs:** 9,000 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 add a new protocol, run the benchmarks, and verify the results. |
+| **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. |
+| 1. | Demo proofs | We will implement 2 zero knowledge proofs ([_Sudoku_](https://en.wikipedia.org/wiki/Sudoku) and [_Factorial_](https://en.wikipedia.org/wiki/Factorial)) for a third protocol. |
+| 2. | Article on protocol | We will publish an **article** on our GitHub blog documenting our development journey with the third protocol, highliting pros and cons, along with general comments about usability and suggestions for developers who want to use them. |
+| 3. | Benchmarking program | We will develop a Rust program that will automatically run and benchmark a predetermined set of zero knowledge proofs (at least a _Sudoku_ and a _Factorial_) and export the results in a readable format, like JSON. |
+| 4. | Protocols integration | We will provide an integration of the 3 protocols and the previously developed Demo Proofs for the benchmarking program, which will be used to produce the results. |
+| 5. | Data Visualization tool | We will provide a single page webapp to easily visualize and compare the benchmark results, using [C3.js](https://c3js.org/) or a similar library. |
+| 6. | Article on results | We will publish an **article** on our GitHub blog that explains our research process, the results, and why we decided to proceed with a certain protocol. |
+
+### Milestone 3 — Development phase
+
+- **Estimated Duration:** 6 weeks
+- **FTE:** 1.5
+- **Costs:** 9,000 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 Tux0 can be included in a Tuxedo runtime, and how to interact with it, using Tuxedo's Template Wallet. |
+| **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. |
+| 1. | Tux0 | We will develop a Tuxedo piece that manages a DAP token using zero knowledge proofs. It will be written in Rust, and it will leverage the library identified in the first milestone. |
+| 2. | Tuxedo Wallet Extension | We will extend the Tuxedo Template Wallet to support Tux0 balances and to send Tux0 transactions. This will also be written in Rust. |
+
+## Future Plans
+
+We intend to continue to maintain Tux0 at least until a proper release of Tuxedo's parachain support - which might even come before the delivery of this grant.
+We are interested in testing the zero-knowledge protocol we chose for Tux0 in a parachain environment.
+
+Bader [@CrackTheCode016](https://github.com/CrackTheCode016) suggested we could deploy a Tux0 parathread on Rococo, which would be a huge step forward for Tuxedo as well.
+
+## Referral Program (optional) :moneybag:
+
+- **Referrer:** Joshy Orndorff
+- **Payment Address:** 0x5a335908df9D2C47304338E3b744579Ed7C6a64d (DAI)
+
+## Additional Information :heavy_plus_sign:
+
+We have been part of the Substrate ecosystem since early 2022, so we had the chance to hear about the W3F Grants from various sources: Substrate Builders Program, Polkadot Blockchain Academy, Parity employees, Sub0 2022, and probably more.
+However, it was Joshy the one who suggested us to ask for a grant for this idea, and he deserves a big thank you from both of us.
diff --git a/applications/validators_selection.md b/applications/validators_selection.md
index 0729259771f..315af59ea0f 100644
--- a/applications/validators_selection.md
+++ b/applications/validators_selection.md
@@ -9,7 +9,7 @@
## Project Overview :page_facing_up:
-Response to an RFP [validator-selection-algorithm](https://github.com/w3f/Grants-Program/blob/master/docs/rfps/Open/validator-selection-algorithm.md "validator-selection-algorithm.md").
+Response to an RFP [validator-selection-algorithm](https://github.com/w3f/Grants-Program/blob/master/docs/rfps/validator-selection-algorithm.md "validator-selection-algorithm.md").
### Overview
diff --git a/applications/vue-typescript-substrate-frontend-template.md b/applications/vue-typescript-substrate-frontend-template.md
index b2287ea4353..4ab2a36a13a 100644
--- a/applications/vue-typescript-substrate-frontend-template.md
+++ b/applications/vue-typescript-substrate-frontend-template.md
@@ -3,6 +3,7 @@
- **Team Name:** Wunderbar Network
- **Payment Address:** 0x6F76BED39E9B9D57cAb4d9b81D65d2fa088cB68E (DAI)
- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2
+- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1601#issuecomment-1758669016)
## Project Overview :page_facing_up:
diff --git a/applications/xNFT.md b/applications/xNFT.md
index 934b80b2dfd..6bc1b7e91e7 100644
--- a/applications/xNFT.md
+++ b/applications/xNFT.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-This application is in response to the open RFP [xcm-tools](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/xcm-tool.md)
+This application is in response to the open RFP [xcm-tools](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/xcm-tool.md)
### Overview
@@ -99,7 +99,7 @@ We are the technical partners for [Peer Coin](https://explorer.peer.inc/)
## Development Status :open_book:
-[xcm-tools](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/xcm-tool.md)
+[xcm-tools](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/xcm-tool.md)
## Development Roadmap :nut_and_bolt:
diff --git a/applications/xcm-tools.md b/applications/xcm-tools.md
index 8b939b9fe46..bf042efff8d 100644
--- a/applications/xcm-tools.md
+++ b/applications/xcm-tools.md
@@ -6,7 +6,7 @@
## Project Overview :page_facing_up:
-RFPs [https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/xcm-tool.md](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/xcm-tool.md)
+RFPs [https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/xcm-tool.md](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/xcm-tool.md)
### Overview
diff --git a/applications/zkwasm-rollups-transfer.md b/applications/zkwasm-rollups-transfer.md
index b1d7b66e521..f543e233426 100644
--- a/applications/zkwasm-rollups-transfer.md
+++ b/applications/zkwasm-rollups-transfer.md
@@ -111,9 +111,9 @@ Through this grant, we are going to implement the **zkwasm** which supports tran
### Overview
-- **Total Estimated Duration:** 11 months
+- **Total Estimated Duration:** 5 months
- **Full-Time Equivalent (FTE):** 2 FTE
-- **Total Costs:** 40,000 USDT
+- **Total Costs:** 20,000 USDT
### Milestone 1 | Crypto Primitive
@@ -134,13 +134,13 @@ In `Milestone 1`, we are going to implement `RedDSA`, optimize `Jubjub` curve an
| 2. | `Jubjub` curve optimization | `Jubjub` curve optimization allows us to perform elliptic curve arithmetic quickly. In our scheme, zero-knowledge prover time is latency when users send transaction and verification time is gas cost on chain. Specifically, we implement [Twisted Edwards Curves Revisited](https://iacr.org/archive/asiacrypt2008/53500329/53500329.pdf), [Jacobian Coordinates](https://eprint.iacr.org/2014/1014.pdf) and [wNAF](https://www.scitepress.org/papers/2014/50587/50587.pdf), [pippenger](https://cr.yp.to/papers/pippenger.pdf). |
|3. | Client wallet implementation |We are going to implement client wallet of `RedDSA`. With this wallet, user can generate private key and one time signing key, and delegate their proof generation, in addition to normal wallet functionalities through RPC.|
-### Milestone 2 | Plonk Extension
+### Milestone 2 | Nova Folding Recursive Snarks Pallet
- **Estimated duration:** 3 month
- **FTE:** 2
- **Costs:** 10,000 USDT
-In `Milestone 2`, we are going to implement `plookup` and recursion on top of [plonk](https://github.com/zero-network/dusk-plonk). These can improve the performance and prove the validity of several circuits separatelly.
+In `Milestone 2`, we are going to implement [Nova folding scheme](https://eprint.iacr.org/2021/370.pdf) which allows light weight recursive Snarks.
| Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
@@ -149,60 +149,20 @@ In `Milestone 2`, we are going to implement `plookup` and recursion on top of [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 Dockerfiles that can be used to test all the functionality delivered with this milestone. |
| 0e. | Article | We will publish an article/tutorial/workshop that explains |
-| 1. | `plookup` implementation | We are going to implement `plookup` to our [plonk](https://github.com/zero-network/dusk-plonk). `plookup` allows us to use precomputed lookup table in zero knowledge circuit and reduce complexity of circuit.|
-| 2. | `recursive proof` implementation | We are going to implement `recursive proof` to our [plonk](https://github.com/zero-network/dusk-plonk). `recursive proof` allows us to generate aggregation circuit and bundle **wasm** ISA proofs to one.|
-| 3. | circuit implementation | We are going to implement zero knowledge circuit which supports combination of `plookup` and `recursive proof`. This circuit allows us to implement the circuit for **zkwasm**.|
-
-### Milestone 3 | Zk Wasm Transfer Prover and Verifier
-
-- **Estimated duration:** 1.5 month
-- **FTE:** 2
-- **Costs:** 10,000 USDT
-
-In `Milestone 3`, we are going to implement `plookup` and `recursive proof` on top of [plonk](https://github.com/zero-network/dusk-plonk). These can improve the performance and prove the validity of several circuits separatelly.
-
-| 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 users prove the validity of **wasm** ISA execution. |
-| 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 Dockerfiles that can be used to test all the functionality delivered with this milestone. |
-| 0e. | Article | We will publish an article/tutorial/workshop that explains |
-| 1. | **wasm** circuit implementation | We are going to implement zero knowledge circuit for **wasm** ISA. The transfer transaction consists of **wasm** ISA. We divide it into read and write access to each resource and prove with `plookup` and `recursive proof`.|
-| 2. | proof generator implementation | We are going to implement proof generator which generates the proof for **wasm** ISA. The input is execution trace of **wasm** ISA and output is zero knowledge proof. This is implemented on off-chain.|
-| 3. | proof verification implementation | We are going to implement proof verification function which verifies the proof. This is implemented on on-chain.|
-
-### Milestone 4 | Zk Wasm Transfer Rollup Node
-
-- **Estimated duration:** 1.5 month
-- **FTE:** 2
-- **Costs:** 10,000 USDT
-
-In `Milestone 4`, we are going to implement rollup node. This can aggregate transfer transactions and generate proof.
-
-| 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 users setup the node and send transfer transactions. |
-| 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 Dockerfiles that can be used to test all the functionality delivered with this milestone. |
-| 0e. | Article | We will publish an article/tutorial/workshop that explains |
-| 1. | rollup node implementation | We are going to implement rollup node. This allows to setup the execution environment of L2 transfer transactions, generate the proof and commit the state to mainchain.|
-| 2. | client transactor implementation | We are going to implement client library to request transfer transactions to rollup node. This is the combination of Redsa wallet and proof generator. |
-| 3. | integrate network | We are going to integrate network. There are four actor mainchain, rollup node and transactor, prover. The transactor generates the transaction and delegate proof generation to prover. The prover generates proof and send it back to transactor. The transactor send transaction to rollup node. The rollup node aggregates these transaction and commit the state to mainchain. |
+| 1. | `bn254/grumpkin` implementation | We are going to implement fully Polkadot compatible `bn254/grumpkin` curve for efficient verifier encoder by [cycle of curves](https://eprint.iacr.org/2023/969.pdf).|
+| 2. | `groth16` implementation | We are going to implement fully Polkadot compatible `groth16` for recursive Snarks verifier circuit.|
+| 3. | `recursive proof` implementation | We are going to implement `recursive proof` with Nova folding scheme. `recursive proof` allows us to compress multiple statements to prove.|
+| 4. | `Nova pallet` implementation | We are going to implement `Nova folding pallet`. `Nova folding pallet` allows us to verify Nova recursive proof which proves multiple statements with a single proof.|
## Timeline
| Milestone | Deliverable | Estimated Duration (month) | Deadline |
| -----: | ----------- | ------------- | ------------- |
| 1 | Crypto Primitive | 2 | 2023 7/31 |
-| 2 | Plonk Extension | 3 | 2023 10/31 |
-| 3 | Zk Wasm Transfer Prover and Verifier | 1.5 | 2023 12/14 |
-| 4 | Zk Wasm Transfer Rollup Node | 1.5 | 2024 1/31 |
+| 2 | Nova Folding | 3 | 2023 11/30 |
## Future Plans
-- Fully zkwasm rollup
- Proof for XCMP
- FHE
- Verifiable hardware
diff --git a/docs/Introduction/intro.md b/docs/Introduction/intro.md
index fc02ed87e87..8b8a25e9a0f 100644
--- a/docs/Introduction/intro.md
+++ b/docs/Introduction/intro.md
@@ -4,28 +4,34 @@ sidebar_position: 1
# Guidelines
-Anyone is welcome to apply for a grant. Projects funded through our programs are broad in scope, but our focus lies on strong **technical** projects that add value to the ecosystem.
+While applications are open to all, the W3F grants program prioritizes projects with a **strong technical focus** that demonstrably add value to the Polkadot ecosystem. Furthermore, successful applicants will be expected to present a solid and compelling long-term roadmap, supported by evidence of the project's significance to the community. This could include:
+
+- Research-oriented projects: Demonstrated significance to the community and potential impact through academic publications or community engagement metrics.
+- Business-oriented projects: A comprehensive market analysis documenting target audience, market size, competitive landscape, and go-to-market strategy.
+- Open-source projects: Proven experience in building strong communities, evidenced by user adoption, active development contributions, and community engagement initiatives.
Generally, your project will have better chances to be accepted if:
-- It presents a **well-researched** or tested concept, for which ideally you are able to show some prior work.
-- You can demonstrate that the project will be **maintained** after completion of the grant, be it through an obvious commitment to the technology from your side, additional funding sources or an existing business model.
-- Your team has **proven experience** with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine these for past activity and code quality. Naturally, you can also link to projects on other platforms.
-- Your application is **rich in technical details** and well-defined.
-- You can clearly present how your project stands out among competitors or implements technology that doesn't exist in the ecosystem yet.
+- it presents a **well-researched** or tested concept, for which ideally you are able to show some prior work;
+- you have tangible proof of how and to what extent the project is a **benefit to the Polkadot ecosystem** and its users;
+- you can demonstrate that the project will be **maintained** after completion of the grant, be it through an obvious commitment to the technology from your side, additional funding sources, or an existing business model;
+- your team has **proven experience** with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine for past activity and code quality. Naturally, you can also link to projects on other platforms;
+- your application is **rich in technical details** and well-defined;
+- you can present how your project stands out among competitors or implements technology that **doesn't exist** in the ecosystem yet.
Additionally, it must fulfill the following requirements:
-- All code produced as part of a grant must be **open-sourced**, and it must also not rely on closed-source software for full functionality. We prefer Apache 2.0, but GPLv3, MIT or Unlicense are also acceptable.
-- 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.
+- 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.
+- The beneficiaries of the grant must successfully go through a **KYC/KYB check** during the application phase in order to be eligible.
In addition to the information provided on your application, note that your project will need to comply with our [Guidelines for Milestone Deliverables](../Support%20Docs/milestone-deliverables-guidelines.md). In particular, we require all projects to create documentation that explains how their project works. At a minimum, _written_ documentation is required for funding. Tutorials or videos are also helpful for new users to understand how to use your product.
Please also heed our [Announcement Guidelines](../Support%20Docs/announcement-guidelines.md) for grant-related communications.
-Finally, we take licensing and the right of all teams in and outside the ecosystem to be recognised for their work very seriously. Using others' work with no attribution or indication that this was not your own work as part of a milestone delivery **will lead to immediate termination**. Please reach out to us before submitting if you have any doubts on how to comply with a specific license and we'll be happy to help.
+Finally, we take licensing and the right of all teams in and outside the ecosystem to be recognized for their work very seriously. Using others' work with no attribution or indication that this was not your own work as part of a milestone delivery **will lead to immediate termination**. Please reach out to us before submitting if you have any doubts on how to comply with a specific license and we'll be happy to help.
-We also try to enforce our [code of conduct](../../CODE_OF_CONDUCT.md) and based on this may [block users](https://github.blog/2016-04-04-organizations-can-now-block-abusive-users/).
+We also try to enforce our [code of conduct](../../CODE_OF_CONDUCT.md) and, based on this, may [block users](https://github.blog/2016-04-04-organizations-can-now-block-abusive-users/).
diff --git a/docs/Introduction/team.md b/docs/Introduction/team.md
index a267b0379dd..f64fe43ea4a 100644
--- a/docs/Introduction/team.md
+++ b/docs/Introduction/team.md
@@ -6,19 +6,16 @@ sidebar_position: 5
## W3F Grants Committee
-The committee consists of individuals who know the funding priorities of the Polkadot ecosystem, and is responsible for evaluating grant applications and providing feedback on these.
+The committee consists of individuals who know the funding priorities of the Polkadot ecosystem and is responsible for evaluating grant applications and providing feedback on these.
In cases where a niche expert opinion is desirable, one of the committee members may request such a review.
- [Santiago Balaguer](https://github.com/SBalaguer)
- [Aeron Buchanan](https://github.com/aeronbuchanan)
-- [Gautam Dhameja](https://github.com/gautamdhameja)
- [David Hawig](https://github.com/Noc2)
-- [Diogo Mendonça](https://github.com/dsm-w3f)
- [Sebastian Müller](https://github.com/semuelle)
- [Bill Laboon](https://github.com/laboon)
- [Keegan Quigley](https://github.com/keeganquigley)
-- [Nikhil Ranjan](https://github.com/nikw3f)
- [Raul Romanutti](https://github.com/rrtti)
- [Seraya Takahashi](https://github.com/takahser)
- [Benjamin Weiß](https://github.com/BenWhiteJam)
@@ -29,16 +26,14 @@ 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.
- [David Hawig](https://github.com/Noc2)
-- [Diogo Mendonça](https://github.com/dsm-w3f)
- [Sebastian Müller](https://github.com/semuelle)
- [Keegan Quigley](https://github.com/keeganquigley)
-- [Nikhil Ranjan](https://github.com/nikw3f)
- [Seraya Takahashi](https://github.com/takahser)
+- [Piet Wolff](https://github.com/PieWol)
## W3F Operations Team
The Operations Team takes care of legal documents, invoicing and remittances.
- [Melanie Diener](https://github.com/meldien)
-- [Federica Dubbini](https://github.com/fededubbi)
- [Rouven Pérez](https://github.com/RouvenP)
diff --git a/docs/Process/how-to-apply.md b/docs/Process/how-to-apply.md
index c48f43b3ab5..092475c2f4e 100644
--- a/docs/Process/how-to-apply.md
+++ b/docs/Process/how-to-apply.md
@@ -9,7 +9,7 @@ If you want to apply in **private**, you can do so [:arrow_right: here](https://
:::
:::info
-Payments can be made in USDT and USDC on the Polkadot [AssetHub](https://wiki.polkadot.network/docs/learn-assets), Bitcoin and fiat (USD, EUR, CHF). Please indicate your preference in the application [as outlined in our application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md?plain=1#L7).
+Payments can be made in USDT and USDC on the Polkadot [AssetHub](https://wiki.polkadot.network/docs/learn-assets) and fiat (USD, EUR, CHF). Please indicate your preference in the application [as outlined in our application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md?plain=1#L7).
:::
@@ -19,7 +19,7 @@ Payments can be made in USDT and USDC on the Polkadot [AssetHub](https://wiki.po
2. [Fork](https://github.com/w3f/Grants-Program/fork) our grants program repository.
3. In the newly created fork, create a copy of the [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md). If you're using the GitHub web interface, you will need to create a new file and copy the [contents](https://raw.githubusercontent.com/w3f/Grants-Program/master/applications/application-template.md) of the template inside the new one. Make sure you **do not modify the template file directly**. In the case of a maintenance application, use the [maintenance template](https://github.com/w3f/Grants-Program/blob/master/maintenance/maintenance-template.md) instead.
4. Name the new file after your project: `project_name.md`.
- 5. Fill out the template with the details of your project. The more information you provide, the faster the review. Please refer to our [Grant guidelines for most popular grant categories](../Support%20Docs/grant_guidelines_per_category.md) and make sure your deliverables present a similar same level of detail. To get an idea of what a strong application looks like, you can have a look at the following examples: [1](https://github.com/w3f/Grants-Program/blob/master/applications/project_aurras_mvp_phase_1.md), [2](https://github.com/w3f/Grants-Program/blob/master/applications/project_bodhi.md), [3](https://github.com/w3f/Grants-Program/blob/master/applications/pontem.md), [4](https://github.com/w3f/Grants-Program/blob/master/applications/spartan_poc_consensus_module.md). Naturally, if you're only applying for a smaller grant that only consists of, say, UI work, you don't need to provide as much detail.
- 6. Once you're done, create a pull request in **our** main [Grants-Program repository](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/README.md). The pull request should only contain _one new file_—the Markdown file you created from the template.
+ 5. Fill out the template with the details of your project. The more information you provide, the faster the review. Please refer to our [Grant guidelines for most popular grant categories](../Support%20Docs/grant_guidelines_per_category.md) and make sure your deliverables present a similar level of detail. To get an idea of what a strong application looks like, you can have a look at the following examples: [1](https://github.com/w3f/Grants-Program/blob/master/applications/project_aurras_mvp_phase_1.md), [2](https://github.com/w3f/Grants-Program/blob/master/applications/project_bodhi.md), [3](https://github.com/w3f/Grants-Program/blob/master/applications/pontem.md), [4](https://github.com/w3f/Grants-Program/blob/master/applications/spartan_poc_consensus_module.md). Naturally, if you're only applying for a smaller grant that only consists of, say, UI work, you don't need to provide as much detail.
+ 6. Once you're done, create a pull request. The pull request should only contain _one new file_—the Markdown file you created from the template.
7. You will see a comment template that contains a checklist. You can leave it as is and tick the checkboxes once the pull request has been created. Please read through these items and check all of them.
8. Sign off on the [terms and conditions](../Support%20Docs/T&Cs.md) presented by the [CLA assistant](https://github.com/claassistantio) bot as a Contributor License Agreement. You might need to reload the pull request to see its comment.
diff --git a/docs/RFPs/Under Development/IDE_for_ink_Smart_Contracts.md b/docs/RFPs/IDE_for_ink_Smart_Contracts.md
similarity index 88%
rename from docs/RFPs/Under Development/IDE_for_ink_Smart_Contracts.md
rename to docs/RFPs/IDE_for_ink_Smart_Contracts.md
index 06640b5994f..4bec3b730bf 100644
--- a/docs/RFPs/Under Development/IDE_for_ink_Smart_Contracts.md
+++ b/docs/RFPs/IDE_for_ink_Smart_Contracts.md
@@ -1,5 +1,9 @@
# Browser based IDE for ink! Smart Contracts
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/ink-playground-ide-improvements.md), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/sandox.md)
* **Proposer:** [David Hawig](https://github.com/Noc2)
diff --git a/docs/RFPs/Open/ISO_20022.md b/docs/RFPs/ISO_20022.md
similarity index 93%
rename from docs/RFPs/Open/ISO_20022.md
rename to docs/RFPs/ISO_20022.md
index 6d2c1611c53..5070b715d61 100644
--- a/docs/RFPs/Open/ISO_20022.md
+++ b/docs/RFPs/ISO_20022.md
@@ -1,5 +1,9 @@
# RFP: ISO 20022
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
* **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/ISO20022.md)
* **Proposer:** [Noc2](https://github.com/Noc2)
diff --git a/docs/RFPs/Under Development/ISO_8583.md b/docs/RFPs/ISO_8583.md
similarity index 81%
rename from docs/RFPs/Under Development/ISO_8583.md
rename to docs/RFPs/ISO_8583.md
index c22ea4b91d5..fed29ec2806 100644
--- a/docs/RFPs/Under Development/ISO_8583.md
+++ b/docs/RFPs/ISO_8583.md
@@ -1,5 +1,9 @@
# RFP: ISO 8583
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/Integrating-ISO8583.md), [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/ISO-8583-implementation.md)
* **Proposer:** [Noc2](https://github.com/Noc2)
@@ -7,7 +11,7 @@
ISO 8583 is an international standard for systems that exchange electronic transactions initiated by cardholders using payment cards. It defines a message format and a communication flow, but offers also custom fields and custom usages. Most transactions that involve ATMs are based on this standard and Mastercard, Visa and Verve networks base their authorization communications on the ISO 8583 standard.
-Even though ISO 8583 is going to be replaced by [ISO 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/ISO_20022.md), it might take some time before it’s actually fully replaced.
+Even though ISO 8583 is going to be replaced by [ISO 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_20022.md), it might take some time before it’s actually fully replaced.
The goal of this RFP is to find teams that implement tools that make it easy and possible for the traditional finance industry to leverage substrate and ink! smart contracts to interact with ISO 8583 in various ways. These tools could be, but are not limited to:
diff --git a/docs/RFPs/Under Development/Static-Analysis-for-Runtime-Pallets.md b/docs/RFPs/Static-Analysis-for-Runtime-Pallets.md
similarity index 92%
rename from docs/RFPs/Under Development/Static-Analysis-for-Runtime-Pallets.md
rename to docs/RFPs/Static-Analysis-for-Runtime-Pallets.md
index ad50f2d40d4..d563bae75b0 100644
--- a/docs/RFPs/Under Development/Static-Analysis-for-Runtime-Pallets.md
+++ b/docs/RFPs/Static-Analysis-for-Runtime-Pallets.md
@@ -1,4 +1,9 @@
# Static Analysis of Runtime Pallets
+
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/sarp-basic-functionality.md)
* **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2)
diff --git a/docs/RFPs/Closed/a-and-v-topology.md b/docs/RFPs/a-and-v-topology.md
similarity index 81%
rename from docs/RFPs/Closed/a-and-v-topology.md
rename to docs/RFPs/a-and-v-topology.md
index 88d7703b0d8..507c9a5428d 100644
--- a/docs/RFPs/Closed/a-and-v-topology.md
+++ b/docs/RFPs/a-and-v-topology.md
@@ -1,13 +1,17 @@
# Availability and Validity - Network Topology
-* **Status:** Closed, since research is outdated
-* **Proposer:** @infinity0, @skalman, @mmagician
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
-## Project Description :page_facing_up:
+- **Status:** Closed, since research is outdated
+- **Proposer:** @infinity0, @skalman, @mmagician
-A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficienct block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators.
+## Project Description :page_facing_up:
-The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validitiy of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain.
+A part of the promise of Polkadot is to bring scalability to the blockchains. The way it achieves it is via delegating application-specific logic from layer 0 (the relay chain) to layer 1 chains (parachains). In order to achieve this efficiently yet securely, each parachain has its own block production mechanism (achieving efficient block production), but the finalisation of candidate parachain blocks still happens with the involvement of the relay chain validators.
+
+The full mechanism is described in [the host specification](https://spec.polkadot.network/chapter-anv). In short, it is split into two parts: first, a publicly known subset of validators attests that the parachain block data is available to them (i.e., they must have it in their local storage); second, once 2/3+ of the first group have published their availability votes, a "secret" (VRF-based assignment) subset of validators checks the validity of the candidate, by checking its state transition against that parachain runtime, which is available on-(the relay)chain.
Currently, the gossip network among the relay chain validators does not make use of the public assignment of a the first subgroup of validators to a particular parachain. Instead, the candidate block is passed around the network until it reaches 2/3+ of approvals, causing an additional delay in the process of finalization of the candidate.
@@ -15,21 +19,22 @@ This proposal aims to solve this issue by creating a selective networking topolo
## Deliverables :nut_and_bolt:
-* **Total Estimated Duration:** 14 weeks
-* **Total Costs:** 90,000 DAI
+- **Total Estimated Duration:** 14 weeks
+- **Total Costs:** 90,000 DAI
### Milestone 1 - update & implementation plan
Given that the above linked research document was produced almost a [year ago](https://github.com/w3f/research/commit/f1a698b34bda8a93433a0f8d9ab1b303c340cb31#diff-13146c2f4b910ccf22483fd1292efdaa079f5b07a966f76716e5bda35a6b3715) (at the time of writing the RFP) and the fast pace of polkadot development, especially parachain development, the first step should be related to understanding and updating, if necessary, that document.
Tasks:
+
- understand what is the current implemention status for parachain networking in Polkadot
- understand in depth what the new topology design tries to achieve
- produce a write-up detailing the differences between current and proposed design
- develop a roadmap for implementation, clearly identifying which parts of the codebase would be affected
-* **Estimated Duration:** 3 weeks
-* **Costs:** 15,000 DAI
+- **Estimated Duration:** 3 weeks
+- **Costs:** 15,000 DAI
### Milestone 2 - Topology discovery by validators
@@ -40,21 +45,23 @@ This milestone is tasked with figuring out the topology for each validator.
Note: The implementer might find that splitting Milestones 2 & 3 is counterproductive, and a more efficient approach is to actually combine these.
Tasks:
+
- perform the calculation of correct network topology for each validator
- add a method that returns the above result. This can either be an RPC method, thus allowing it to be verified externally, or an internal method, where the validators report (could be as simple as console logs) their assignment
- run tests to verify the correctness of the calculation and unanimous consensus
-* **Estimated Duration:** 6 weeks
-* **Costs:** 30,000 DAI
+- **Estimated Duration:** 6 weeks
+- **Costs:** 30,000 DAI
### Milestone 3 - Networking and benchmarking
This should be a "simple" milestone in that it replaces the previous mechanism for candidate block distribution (broadcast medium B) with direct links(D), as proposed in the [Overview](https://research.web3.foundation/en/latest/polkadot/networking/3-avail-valid.html#overview).
-* **Estimated Duration:** 8 weeks
-* **Costs:** 45,000 DAI
+- **Estimated Duration:** 8 weeks
+- **Costs:** 45,000 DAI
Tasks:
+
- apply the topology calculated
- distribute block data along the direct route
- perform an extensive testing & benchmarking exercise on a network with at least 20 validators. The parachain block production can be mocked.
diff --git a/docs/RFPs/Under Development/alternative-polkadot-js-api-console.md b/docs/RFPs/alternative-polkadot-js-api-console.md
similarity index 93%
rename from docs/RFPs/Under Development/alternative-polkadot-js-api-console.md
rename to docs/RFPs/alternative-polkadot-js-api-console.md
index fb2017b4f2c..e6e82dc82f2 100644
--- a/docs/RFPs/Under Development/alternative-polkadot-js-api-console.md
+++ b/docs/RFPs/alternative-polkadot-js-api-console.md
@@ -1,6 +1,10 @@
# Alternative javascript console for Polkadot JS API
-* **Status:** [Under Development](https://w3f.github.io/Grants-Program/applications/sandox)
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
+* **Status:** Closed
* **Proposer:** [muddlebee](https://github.com/muddlebee)
* **Projects you think this work could be useful for** [optional]: Javascript console at https://polkadot.js.org/apps/#/js
diff --git a/docs/RFPs/Under Development/alternative_polkadot_host_implementations.md b/docs/RFPs/alternative_polkadot_host_implementations.md
similarity index 77%
rename from docs/RFPs/Under Development/alternative_polkadot_host_implementations.md
rename to docs/RFPs/alternative_polkadot_host_implementations.md
index 8f182c3fb29..44d2fbe2d64 100644
--- a/docs/RFPs/Under Development/alternative_polkadot_host_implementations.md
+++ b/docs/RFPs/alternative_polkadot_host_implementations.md
@@ -1,9 +1,13 @@
# Alternative Polkadot Host Implementation
-* **Status:** [Under Development 1](https://github.com/LimeChain/java-host-research), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/hybrid_node_research.md)
-* **Proposer:** [Noc2](https://github.com/Noc2)
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
-## Project Description :page_facing_up:
+- **Status:** [Under Development 1](https://github.com/LimeChain/java-host-research), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/hybrid_node_research.md)
+- **Proposer:** [Noc2](https://github.com/Noc2)
+
+## Project Description :page_facing_up:
The architecture of Polkadot can be divided into two different parts, the Polkadot runtime and the Polkadot host. The Polkadot runtime is the core state transition logic of the chain and can be upgraded over the course of time and without the need for a hard fork. In comparison, the Polkadot host is the environment in which the runtime executes and is expected to remain stable and mostly static over the lifetime of Polkadot.
@@ -11,9 +15,9 @@ The Polkadot host interacts with the Polkadot runtime in limited, and well-speci
**The Web3 Foundation is interested in supporting additional implementations of the Polkadot Host. If you are interested in this RFP, please reach out to spec@web3.foundation.**
-Currently the following implementations are under development:
+Currently the following implementations are under development:
-- [Gossamer: A Go implementation of the Polkadot Host](https://github.com/ChainSafe/gossamer)
+- [Gossamer: A Go implementation of the Polkadot Host](https://github.com/ChainSafe/gossamer)
- [Kagome - C++ implementation of Polkadot Host](https://github.com/soramitsu/kagome)
- [Polkadot Node Implementation in Rust](https://github.com/paritytech/polkadot)
- [Smoldot - A Lightweight Substrate and Polkadot client in Rust](https://github.com/paritytech/smoldot)
@@ -27,4 +31,4 @@ For Polkadot Host Implementations, it’s probably too complex to structure the
- Consensus engine for GRANDPA and BABE.
- Wasm interpreter and virtual machine.
- Low level primitives for a blockchain, such as cryptographic primitives like hash functions.
-- Availability & Validity components to support parachains.
\ No newline at end of file
+- Availability & Validity components to support parachains.
diff --git a/docs/RFPs/Under Development/analysis-website-and-data-platform.md b/docs/RFPs/analysis-website-and-data-platform.md
similarity index 91%
rename from docs/RFPs/Under Development/analysis-website-and-data-platform.md
rename to docs/RFPs/analysis-website-and-data-platform.md
index 6d043841d71..272f4dfc53c 100644
--- a/docs/RFPs/Under Development/analysis-website-and-data-platform.md
+++ b/docs/RFPs/analysis-website-and-data-platform.md
@@ -1,5 +1,9 @@
# Analytics Website/Data Platform
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/pull/1716), [Under Development 2](https://github.com/w3f/Grants-Program/pull/1768), [Under Development 3](https://github.com/w3f/Grants-Program/blob/master/applications/fidi-dotsight-analytics.md)
* **Proposer:** [Keegan Quigley](https://github.com/keeganquigley)
* **Teams/People that could deliver the RFP**: @web3go-xyz
diff --git a/docs/RFPs/Open/anti-collusion_infrastructure.md b/docs/RFPs/anti-collusion_infrastructure.md
similarity index 86%
rename from docs/RFPs/Open/anti-collusion_infrastructure.md
rename to docs/RFPs/anti-collusion_infrastructure.md
index 7c202fdfa3f..f9616d3682d 100644
--- a/docs/RFPs/Open/anti-collusion_infrastructure.md
+++ b/docs/RFPs/anti-collusion_infrastructure.md
@@ -1,6 +1,10 @@
# Anti-Collusion Infrastructure
-* **Status:** Open
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
+* **Status:** [Under Development](https://grants.web3.foundation/applications/infimum)
* **Proposer:** [Noc2](https://github.com/Noc2)
## Project Description :page_facing_up:
diff --git a/docs/RFPs/Closed/appi.md b/docs/RFPs/appi.md
similarity index 98%
rename from docs/RFPs/Closed/appi.md
rename to docs/RFPs/appi.md
index ac3053d7bf2..e6fdad4d8eb 100644
--- a/docs/RFPs/Closed/appi.md
+++ b/docs/RFPs/appi.md
@@ -1,5 +1,9 @@
# APPI: Auto-funded public P2P infrastructure
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented](https://github.com/nodefactoryio/vedran)
* **Proposer:** [swader](https://github.com/swader)
* **Projects you think this work could be useful for**: https://kusama.network, https://polkadot.network
diff --git a/docs/RFPs/Closed/bpf-contracts.md b/docs/RFPs/bpf-contracts.md
similarity index 96%
rename from docs/RFPs/Closed/bpf-contracts.md
rename to docs/RFPs/bpf-contracts.md
index d85483256ba..c21f2db056c 100644
--- a/docs/RFPs/Closed/bpf-contracts.md
+++ b/docs/RFPs/bpf-contracts.md
@@ -1,5 +1,9 @@
# BPF-based ink! smart contracts
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Closed](https://forum.polkadot.network/t/ebpf-contracts-hackathon/1084/13?u=david)
* **Proposer:** [takahser](https://github.com/takahser)
diff --git a/docs/RFPs/Closed/candle-auction.md b/docs/RFPs/candle-auction.md
similarity index 95%
rename from docs/RFPs/Closed/candle-auction.md
rename to docs/RFPs/candle-auction.md
index 538aca19bea..4e2ca6c5902 100644
--- a/docs/RFPs/Closed/candle-auction.md
+++ b/docs/RFPs/candle-auction.md
@@ -1,5 +1,9 @@
# Candle auction smart contract
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented](https://github.com/agryaznov/candle-auction-ink/tree/master)
* **Proposer:** [mmagician](https://github.com/mmagician)
diff --git a/docs/RFPs/Closed/crowdloan_front_end_template.md b/docs/RFPs/crowdloan_front_end_template.md
similarity index 83%
rename from docs/RFPs/Closed/crowdloan_front_end_template.md
rename to docs/RFPs/crowdloan_front_end_template.md
index 21edca3a6e2..f791a88a313 100644
--- a/docs/RFPs/Closed/crowdloan_front_end_template.md
+++ b/docs/RFPs/crowdloan_front_end_template.md
@@ -1,5 +1,9 @@
# Crowdloan Front End Template
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented](https://github.com/w3f/Grant-Milestone-Delivery/pull/765), [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)
@@ -8,12 +12,16 @@
The following document intends to outline what a front-end white-label template could look like for teams to use to easily build their Polkadot Crowdloan ([see Wiki: Parachain Crowdloans](https://wiki.polkadot.network/docs/learn-crowdloans)) websites. Teams applying for this RFP can change and adapt this.
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](#project-information)
-2. [Rewards Schema](#rewards-schema)
-3. [Current contributions](#current-contributions)
-4. [Time left in Crowdloan and competition](#time-left-in-crowdloan-and-competition)
-5. [Contribute CTA](#contribute-cta)
-6. [After the Crowdloan](#after-the-crowdloan)
+- [Crowdloan Front End Template](#crowdloan-front-end-template)
+ - [Project Description :page\_facing\_up:](#project-description-page_facing_up)
+ - [Project Information](#project-information)
+ - [Rewards Schema](#rewards-schema)
+ - [Current Contributions](#current-contributions)
+ - [Time left in Crowdloan and competition](#time-left-in-crowdloan-and-competition)
+ - [Contribute CTA](#contribute-cta)
+ - [After the Crowdloan](#after-the-crowdloan)
+ - [Available Tools](#available-tools)
+ - [Past examples](#past-examples)
All of the above should be done _style agnostic_ so that the project can plug their own look and feel into the site.
diff --git a/docs/RFPs/Under Development/data_analysis_tools.md b/docs/RFPs/data_analysis_tools.md
similarity index 93%
rename from docs/RFPs/Under Development/data_analysis_tools.md
rename to docs/RFPs/data_analysis_tools.md
index 656dd6b0ba4..d0cb5b2b7aa 100644
--- a/docs/RFPs/Under Development/data_analysis_tools.md
+++ b/docs/RFPs/data_analysis_tools.md
@@ -1,5 +1,9 @@
# Data Analysis Tools for Substrate-based Blockchains
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
- **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/pull/1716), [Under Development 2](https://github.com/w3f/Grants-Program/pull/1768), [Under Development 3](https://github.com/w3f/Grants-Program/pull/1883)
- **Proposer:** [dsm-w3f](https://github.com/dsm-w3f), [michalisFr](https://github.com/michalisFr)
diff --git a/docs/RFPs/Under Development/decentralized-security-marketplace.md b/docs/RFPs/decentralized-security-marketplace.md
similarity index 92%
rename from docs/RFPs/Under Development/decentralized-security-marketplace.md
rename to docs/RFPs/decentralized-security-marketplace.md
index 53f23905e48..895eee20719 100644
--- a/docs/RFPs/Under Development/decentralized-security-marketplace.md
+++ b/docs/RFPs/decentralized-security-marketplace.md
@@ -1,5 +1,9 @@
# Decentralized Security Marketplace
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Under Development](https://github.com/w3f/Grants-Program/pull/1726)
* **Proposer:** [Matteo Casonato](https://github.com/0xCaso), [Bhargav Batt](https://github.com/bhargavbh)
diff --git a/docs/RFPs/Closed/epassport-zk-validation.md b/docs/RFPs/epassport-zk-validation.md
similarity index 93%
rename from docs/RFPs/Closed/epassport-zk-validation.md
rename to docs/RFPs/epassport-zk-validation.md
index 6f3d2706fc1..301ff0a4474 100644
--- a/docs/RFPs/Closed/epassport-zk-validation.md
+++ b/docs/RFPs/epassport-zk-validation.md
@@ -1,5 +1,8 @@
# e-Passport ZK Validation [ON HOLD PENDING REVISIONS]
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
* **Status:** On Hold
* **Proposer:** [burges](https://github.com/burges), [FlorianFranzen](https://github.com/FlorianFranzen)
@@ -49,6 +52,6 @@ Later, the proof is uploaded on-chain, and the chain logic performs verification
* **Estimated Duration:** 1 month
* **Costs:** 20,000 kUSD
-The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furhtermore, countries are expected to publish the revocations of any compromised certificates.
+The Master List is expected to, albeit unfrequently, receive updates as new countries join the PKD or as they update their certificates periodically. Furthermore, countries are expected to publish the revocations of any compromised certificates.
It is important that both prover and verifier circuits are updated accordingly - else the proof won't match.
diff --git a/docs/RFPs/Open/formal_guarantees_for_grandpa.md b/docs/RFPs/formal_guarantees_for_grandpa.md
similarity index 90%
rename from docs/RFPs/Open/formal_guarantees_for_grandpa.md
rename to docs/RFPs/formal_guarantees_for_grandpa.md
index dce19cb08b7..94649968635 100644
--- a/docs/RFPs/Open/formal_guarantees_for_grandpa.md
+++ b/docs/RFPs/formal_guarantees_for_grandpa.md
@@ -1,4 +1,9 @@
# Formal Guarantees for GRANDPA Finality Gadget
+
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
* **Status:** Open
* **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2)
@@ -13,7 +18,7 @@ We are open to any reasonable formal methods approach that rigorously proves the
- interactive theorem proving (in Isabelle/HOL, Coq, verdi)
- Any other temporal property verification tool for distributed systems
-We envision the project to prove both safety and liveness properties of GRANDPA which interacts with a Block Production mechanism (like [BABE](https://research.web3.foundation/en/latest/polkadot/block-production/Babe.html) or [Sassafras](https://research.web3.foundation/en/latest/polkadot/block-production/SASSAFRAS.html)) by assuming an abstract interface.
+We envision the project to prove both safety and liveness properties of GRANDPA which interacts with a Block Production mechanism (like [BABE](https://research.web3.foundation/Polkadot/protocols/block-production/Babe) or [Sassafras](https://research.web3.foundation/Polkadot/protocols/block-production/SASSAFRAS)) by assuming an abstract interface.
## Deliverables
diff --git a/docs/RFPs/Under Development/grant_management_webapp.md b/docs/RFPs/grant_management_webapp.md
similarity index 96%
rename from docs/RFPs/Under Development/grant_management_webapp.md
rename to docs/RFPs/grant_management_webapp.md
index 7e4c23aaa21..17a865f5030 100644
--- a/docs/RFPs/Under Development/grant_management_webapp.md
+++ b/docs/RFPs/grant_management_webapp.md
@@ -1,6 +1,10 @@
# Grant Management Web Application
-* **Status:** Under Development [here](https://github.com/w3f/Grants-Program/pull/1766) as well as [here](https://github.com/w3f/Grants-Program/pull/1765)
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
+* **Status:** Closed
* **Proposer:** [randombishop](https://github.com/randombishop)
diff --git a/docs/RFPs/Under Development/identity-directory.md b/docs/RFPs/identity-directory.md
similarity index 94%
rename from docs/RFPs/Under Development/identity-directory.md
rename to docs/RFPs/identity-directory.md
index be652056b5b..5bc40ce5164 100644
--- a/docs/RFPs/Under Development/identity-directory.md
+++ b/docs/RFPs/identity-directory.md
@@ -1,5 +1,9 @@
# RFP: Substrate Identity Directory
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/SubIdentity.md), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/Dotflow.md)
* **Proposer:** swader
* **Projects you think this work could be useful for**: Kusama, Polkadot, Substrate chains
@@ -47,7 +51,7 @@ The individual events and positions in the various columns should be **linkable*
#### Default Plugins
- `basic info`: a column with basic information about an account, similar to the sidebar on Polkadot JS Apps UI. Should discern between registrars - it should list each registrar who verified this identity and the verification level they gave (i.e. KnownGood vs KnownBad etc.)
-- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as decribed above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member).
+- `governance`: a column listing all of an account's governance activity like votes, proposals, marking the times when the account was a council member, etc. It should resemble a vertical timeline, with related events referencing each other, quoted-tweet style. Events should be linkable as described above, i.e. `governance@477723`. The column should **clearly** mark when a user was a council member but failed to uphold their duties, i.e. there was a motion but the user did not vote, and other interesting info (i.e. the user did not do ANYTHING the council can do while being a council member).
- `treasury`: a history of an account's interactions with the treasury - tip proposals and endorsements, treasury proposals and grant wins, votes on TP motions if user was council at the time (and clear marks if the user FAILED to vote on a TP motion during his activity as councilor).
- `validator`: showing the history/summary of the account's participation in securing the network
#### Optional Plugins
diff --git a/docs/RFPs/Under Development/implementation-benchmarking.md b/docs/RFPs/implementation-benchmarking.md
similarity index 95%
rename from docs/RFPs/Under Development/implementation-benchmarking.md
rename to docs/RFPs/implementation-benchmarking.md
index 48acc6fb1a0..1b0cc12afe3 100644
--- a/docs/RFPs/Under Development/implementation-benchmarking.md
+++ b/docs/RFPs/implementation-benchmarking.md
@@ -1,5 +1,9 @@
# ink!/pallet/solidity performance benchmarking
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
- **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/ink-pallet-benchmarking.md)
- **Proposer:** [mmagician](https://github.com/mmagician)
diff --git a/docs/RFPs/Under Development/ink_smart_contract_block_explorer.md b/docs/RFPs/ink_smart_contract_block_explorer.md
similarity index 72%
rename from docs/RFPs/Under Development/ink_smart_contract_block_explorer.md
rename to docs/RFPs/ink_smart_contract_block_explorer.md
index fae0d22e091..2ecb2227bc6 100644
--- a/docs/RFPs/Under Development/ink_smart_contract_block_explorer.md
+++ b/docs/RFPs/ink_smart_contract_block_explorer.md
@@ -1,5 +1,9 @@
# RFP: ink! block explorer
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Implemented 1](https://github.com/w3f/Grants-Program/blob/master/applications/epirus_substrate_explorer.md), [Implemented 2](https://github.com/w3f/Grants-Program/blob/master/applications/ink-explorer.md)
* **Proposer:** [Noc2](https://github.com/Noc2)
diff --git a/docs/RFPs/jsonrpsee-proxy-support.md b/docs/RFPs/jsonrpsee-proxy-support.md
new file mode 100644
index 00000000000..5f25149f087
--- /dev/null
+++ b/docs/RFPs/jsonrpsee-proxy-support.md
@@ -0,0 +1,79 @@
+# Socks5 proxy support for JsonRpsee
+
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
+* **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/jsonrpsee-proxy-support.md)
+* **Proposer:** flipchan
+
+## Project Description :page_facing_up:
+
+[JsonRpsee](https://github.com/paritytech/jsonrpsee) is an opensource Rust library used by several para and relay chain client libraries to connect to chains over ws or rpc.
+
+## Background story
+
+Tor is a anonymization project that has been active for several years. By utilizing a traffic obfusication protocol to route data, it enables users to anonymize their internet traffic. Several blockchain projects leverage this technology to allow users to connect to nodes over tor, inputting the .onion address of the rpc provider.
+
+By providing a .onion address for a rpc/ws node, we can allow users to have more privacy by masking the origination of the request (the sender's ip address).
+
+
+Gavin Wood mentioned onion-routing as an important future feature on Decoded 2023:
+
+
+[In february 2023](https://forum.polkadot.network/t/privhost-public-polkadot-kusama-and-edgeware-nodes-with-tor-v3-onion-support/2093), a small public rpc provider was launched in order to provide .onion rpc endpoints for handful of chains in the ecosystem.
+Privhost was later listed on the [awesome-substrate list](https://github.com/substrate-developer-hub/awesome-substrate#products-and-services).
+
+
+In order to connect to a .onion site, a user must pass it's connection through a tor socks5 proxy in order to resolve the .onion domain and connect.
+
+
+Several ecosystem projects want to add support for connecting to .onion, but are blocked due to JsonRpsee not having support for sock5 proxy.
+
+
+Third party pr's that are waiting for JsonRpsee to support socks5:
+- [Fedimint #391](https://github.com/fedimint/fedimint/issues/391#issuecomment-1643878929)
+- [Uptest #15](https://github.com/uptest-sc/uptest/issues/15)
+
+On 4th of September of 2022 a [pr was created](https://github.com/paritytech/jsonrpsee/issues/870) to start the process of adding socks5 support for JsonRpsee.
+Noone has had time to fix this issue and implement this feature, therefor this RFP.
+
+
+## Motivation
+- Enable client libraries to connect to .onion rpc nodes.
+
+
+### Ecosystem projects that rely on JsonRpsee
+- [Subxt](https://github.com/paritytech/subxt)
+- [Substrate](https://github.com/paritytech/substrate)
+- [Subwasm](https://github.com/chevdor/subwasm)
+- [Uptest](https://github.com/uptest-sc/uptest)
+- [Subway](https://github.com/AcalaNetwork/subway)
+
+## Deliverables :nut_and_bolt:
+
+* **Total Estimated Duration:** 4 weeks
+* **Full-time equivalent (FTE):** 4 weeks
+* **Total Costs:** 9000 USD(may be changed by the future team)
+
+
+### Milestone 1
+
+Please add additional milestones in the same way:
+* **Estimated Duration:** Duration of milestone 1
+* **FTE:** 4 weeks
+* **Costs:** 9000 USD(may be changed by the future team)
+
+
+| Number | Deliverable | Specification |
+| ------------- | ------------- | ------------- |
+| 0a. | License | Apache 2.0 / MIT / Unlicense|
+| 0b. | Documentation | Public documentation with implementation guides and sample code |
+| 0c. | Testing Guide |Rust Unit tests|
+| 0d. | Article |Article explaining how to utilize the socks5 support|
+| 1. | Middleware layer | In order to enable socks5 support, several modifications of the `WsTransportClientBuilder` needs to be implemented, described in [issue #1162](https://github.com/paritytech/jsonrpsee/issues/1162) |
+| 2. | Socks5 support |enable a jsonrpsee client to proxy connections using a socks5 proxy |
+
+
+#### Demonstrations
+- Connect to a .onion rpc node with jsonrpsee.
diff --git a/docs/RFPs/Closed/ksm-tipping-button.md b/docs/RFPs/ksm-tipping-button.md
similarity index 93%
rename from docs/RFPs/Closed/ksm-tipping-button.md
rename to docs/RFPs/ksm-tipping-button.md
index 64d3301998e..6142d0b3f6f 100644
--- a/docs/RFPs/Closed/ksm-tipping-button.md
+++ b/docs/RFPs/ksm-tipping-button.md
@@ -1,5 +1,9 @@
# Tip or Donate KSM Embeddable Button
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented](https://github.com/Shard-Labs/kusama-tips-widget)
* **Proposer:** swader
@@ -19,7 +23,7 @@ The tip begins its closing process (a countdown) when more than a half of counci
## Proposal
-The Kusama Tip Button sould be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.
+The Kusama Tip Button should be a standalone embeddable snippet of HTML and JS code. When added to a website, a "Tip or Donate KSM" button should show, text customizable by website owner.
Before the user interacts with the button, the button's embedded code should:
diff --git a/docs/RFPs/Under Development/move_smart_contract_pallet.md b/docs/RFPs/move_smart_contract_pallet.md
similarity index 84%
rename from docs/RFPs/Under Development/move_smart_contract_pallet.md
rename to docs/RFPs/move_smart_contract_pallet.md
index 9cc79f499e5..6f3082806e9 100644
--- a/docs/RFPs/Under Development/move_smart_contract_pallet.md
+++ b/docs/RFPs/move_smart_contract_pallet.md
@@ -1,4 +1,9 @@
# Move Smart Contract Pallet
+
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Under Development](https://github.com/w3f/Grants-Program/blob/master/applications/Substrate_Move_System_Pallet_1.md)
* **Proposer:** [David Hawig](https://github.com/Noc2)
diff --git a/docs/RFPs/Closed/multi-chain-block-explorer.md b/docs/RFPs/multi-chain-block-explorer.md
similarity index 86%
rename from docs/RFPs/Closed/multi-chain-block-explorer.md
rename to docs/RFPs/multi-chain-block-explorer.md
index 2d413cb3104..54f4f891832 100644
--- a/docs/RFPs/Closed/multi-chain-block-explorer.md
+++ b/docs/RFPs/multi-chain-block-explorer.md
@@ -1,5 +1,9 @@
# Multi-chain Block Explorer
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented 1](https://github.com/colorfulnotion/polkaholic), [Implemented 2](https://polkadot.subscan.io/)
* **Teams/People that could deliver the RFP:** @clearloop, @carlhong
diff --git a/docs/RFPs/Closed/on-chain-quadratic-funding.md b/docs/RFPs/on-chain-quadratic-funding.md
similarity index 97%
rename from docs/RFPs/Closed/on-chain-quadratic-funding.md
rename to docs/RFPs/on-chain-quadratic-funding.md
index 6c5304e6518..f6d3746cd15 100644
--- a/docs/RFPs/Closed/on-chain-quadratic-funding.md
+++ b/docs/RFPs/on-chain-quadratic-funding.md
@@ -1,5 +1,9 @@
# On-chain Quadratic Funding
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implementation by Dora](https://github.com/zhangjiannan/QFgrant), [Implementation by OAK](https://github.com/OAK-Foundation/quadratic-funding-pallet/tree/master)
* **Proposer:** [Noc2](https://github.com/Noc2)
diff --git a/docs/RFPs/Open/parachain_validation_conformance_testing.md b/docs/RFPs/parachain_validation_conformance_testing.md
similarity index 56%
rename from docs/RFPs/Open/parachain_validation_conformance_testing.md
rename to docs/RFPs/parachain_validation_conformance_testing.md
index 3c28fba93dd..d2b1f67134c 100644
--- a/docs/RFPs/Open/parachain_validation_conformance_testing.md
+++ b/docs/RFPs/parachain_validation_conformance_testing.md
@@ -1,25 +1,22 @@
# Parachain Validation Conformance Testing
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
* **Status:** Open
* **Proposer:** [bkchr](https://github.com/bkchr)
## Project Description :page_facing_up:
-Each Polkadot host implementation that wants to take part in consensus needs to implement the Parachains protocol. Part of the Parachains
-protocol is the execution of the Parachain Validation Function (`PVF`). The `PVF` is a wasm blob that is required to provide the `validate_block`
-function that takes a fixed set of arguments (part is the proof of validity from a collator), validates the proof of validity and returns (on success) some
-information back to the Polkadot host implementation. The `PVF` is a black box for the Polkadot node and it can only use the `validate_block` to
-make use of it. The execution of these `PVF`s is required to stay in certain limits to reach consensus across different node implementations,
-node versions, different hardware configuration and OS configurations. Some of these limits are:
+Each Polkadot host implementation that wants to take part in consensus needs to implement the Parachains protocol. Part of the Parachains protocol is the execution of the Parachain Validation Function (`PVF`). The `PVF` is a wasm blob that is required to provide the `validate_block` function that takes a fixed set of arguments (part is the proof of validity from a collator), validates the proof of validity and returns (on success) some information back to the Polkadot host implementation. The `PVF` is a black box for the Polkadot node and it can only use the `validate_block` to make use of it. The execution of these `PVF`s is required to stay in certain limits to reach consensus across different node implementations, node versions, different hardware configuration and OS configurations. Some of these limits are:
- A deterministic maximum stack depth. All node implementations should support the same stack depth.
- A deterministic maximum memory. All node implementations should support the same maximum memory usage per `PVF` execution.
- A deterministic maximum execution time. All node implementations should execute a given `PVF` in the same maximum time frame.
- A deterministic compilation/preparation of the `PVF`. All node implementations should compile/prepare a given `PVF` in the same maximum time frame and maximum memory budget.
-There are probably a lot of other limits as well. To ensure that all node implementations/versions are staying in these limits it is required
-to have conformance tests. These should include basic execution of valid wasm files over to complex wasm files that ensure that the compilation/preparation
-stays in the given limits and/or helps to define these limits properly across different implementations.
+There are probably a lot of other limits as well. To ensure that all node implementations/versions are staying in these limits it is required to have conformance tests. These should include basic execution of valid wasm files over to complex wasm files that ensure that the compilation/preparation stays in the given limits and/or helps to define these limits properly across different implementations.
**Useful resources:**
- [The Polkadot Parachain Host Implementers' Guide](https://paritytech.github.io/polkadot/book/index.html)
@@ -31,6 +28,5 @@ stays in the given limits and/or helps to define these limits properly across di
- Conformance tests that are resulting in running over the limits.
- Fuzzing across different implementations ensuring that all are coming to the same result
-This is more some never ending task trying to find issues in different implementations, getting them fixed and searching for new vulnerabilities.
-In the end these tests should ensure that updating wasm engines, introducing new node implementations
+This is more some never ending task trying to find issues in different implementations, getting them fixed and searching for new vulnerabilities. In the end these tests should ensure that updating wasm engines, introducing new node implementations
etc can be done in a sane way without hoping for the best.
diff --git a/docs/RFPs/Closed/php-api.md b/docs/RFPs/php-api.md
similarity index 92%
rename from docs/RFPs/Closed/php-api.md
rename to docs/RFPs/php-api.md
index e183b8102bd..dfd6d4392a8 100644
--- a/docs/RFPs/Closed/php-api.md
+++ b/docs/RFPs/php-api.md
@@ -1,5 +1,9 @@
# PHP Substrate API
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Proposer:** [swader](https://github.com/api)
* **Status:** [Implemented](https://github.com/gmajor-encrypt/php-substrate-api)
diff --git a/docs/RFPs/Closed/php-scale.md b/docs/RFPs/php-scale.md
similarity index 84%
rename from docs/RFPs/Closed/php-scale.md
rename to docs/RFPs/php-scale.md
index 08b2239a1b2..1c6161ce63c 100644
--- a/docs/RFPs/Closed/php-scale.md
+++ b/docs/RFPs/php-scale.md
@@ -1,5 +1,9 @@
# PHP Version of SCALE Codec
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Proposer:** [swader](https://github.com/swader)
* **Status:** [Done](https://github.com/w3f/Grants-Program/pull/235)
@@ -11,4 +15,4 @@ The SCALE codec is the de-factor encoding method in Substrate-based chains. It i
The deliverable should be a standalone SCALE codec package, hosted on Packagist. It can (but does not have to) depend on existing Base58 packages already present on Packagist.org.
-The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusivley a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone.
+The package *can* also be delivered as a companion PHP **extension** but the extension should be exclusively a performance upgrade to the existing package. In other words, the Packagist-installable library should work on its own, but can be improved by also downloading the (optional) PHP extension. If the applicant decides to also create the extension, they should submit it as a separate milestone.
diff --git a/docs/RFPs/Closed/polkadot-collator-setup.md b/docs/RFPs/polkadot-collator-setup.md
similarity index 92%
rename from docs/RFPs/Closed/polkadot-collator-setup.md
rename to docs/RFPs/polkadot-collator-setup.md
index f4e116d27c8..fc63b89f51c 100644
--- a/docs/RFPs/Closed/polkadot-collator-setup.md
+++ b/docs/RFPs/polkadot-collator-setup.md
@@ -1,5 +1,9 @@
# Polkadot Collator Setup
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
- **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/unified_collator_node_deployment.md)
- **Proposer:** mmagician
- **Your Project(s):** https://mmagician.github.io/
@@ -16,7 +20,7 @@ I understand it might be tricky to bundle all the parachain launch setups into o
1. Have a single collator ansible role, and each branch would correspond to a specific parachain
2. Have multiple ansible roles, and the main.yml in the project root to coordinate which roles get deployed.
-I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independant chains without meddling with git branching too much.
+I would lean towards the second option. While it might lead to large repo size due to multiple collator setups (and multiple networks - the setup might be different on Kusama or Polkadot), it gives more flexibility to spin up multiple collators for independent chains without meddling with git branching too much.
## Deliverables :nut_and_bolt:
diff --git a/docs/RFPs/Under Development/polkadot-protocol_conformance_tests.md b/docs/RFPs/polkadot-protocol_conformance_tests.md
similarity index 92%
rename from docs/RFPs/Under Development/polkadot-protocol_conformance_tests.md
rename to docs/RFPs/polkadot-protocol_conformance_tests.md
index a262adbda0e..eb713b4addc 100644
--- a/docs/RFPs/Under Development/polkadot-protocol_conformance_tests.md
+++ b/docs/RFPs/polkadot-protocol_conformance_tests.md
@@ -1,5 +1,9 @@
# Polkadot Protocol Conformance Tests
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Under Development (Zondax)](https://github.com/w3f/Grants-Program/pull/1956), [Under Development (LimeChain)](https://github.com/w3f/Grants-Program/pull/1950)
* **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2)
* **Objectives:** Create and maintain a comprehensive test-suite for conformance of core functionalities of Polkadot Host.
diff --git a/docs/RFPs/Closed/privacy-enhancement-polkadot-extension.md b/docs/RFPs/privacy-enhancement-polkadot-extension.md
similarity index 95%
rename from docs/RFPs/Closed/privacy-enhancement-polkadot-extension.md
rename to docs/RFPs/privacy-enhancement-polkadot-extension.md
index e5b991e38f0..5327f87c07d 100644
--- a/docs/RFPs/Closed/privacy-enhancement-polkadot-extension.md
+++ b/docs/RFPs/privacy-enhancement-polkadot-extension.md
@@ -1,5 +1,9 @@
# Privacy Enhancement for Polkadot Extension
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/polkadot-js-extension-per-account-auth.md). GH [issue](https://github.com/polkadot-js/extension/issues/1037) has been closed.
* **Proposer:** jonasW3F
* **Projects you think this work could be useful for** [optional]: https://github.com/polkadot-js/extension
diff --git a/docs/RFPs/Under Development/raft-validators.md b/docs/RFPs/raft-validators.md
similarity index 96%
rename from docs/RFPs/Under Development/raft-validators.md
rename to docs/RFPs/raft-validators.md
index f417142002e..f50119af224 100644
--- a/docs/RFPs/Under Development/raft-validators.md
+++ b/docs/RFPs/raft-validators.md
@@ -1,5 +1,9 @@
# High-availability validator setup
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/High_availability_validator_setup.md)
* **Proposer:** mmagician
* **Projects you think this work could be useful for:** Polkadot & Kusama Validators
diff --git a/docs/RFPs/Closed/scale-codec-comparator.md b/docs/RFPs/scale-codec-comparator.md
similarity index 94%
rename from docs/RFPs/Closed/scale-codec-comparator.md
rename to docs/RFPs/scale-codec-comparator.md
index 79d713fe8fd..96e68f181b0 100644
--- a/docs/RFPs/Closed/scale-codec-comparator.md
+++ b/docs/RFPs/scale-codec-comparator.md
@@ -1,5 +1,9 @@
# SCALE Codec Comparator
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented for ten encoding types](https://github.com/w3f/Grants-Program/blob/master/applications/scale-codec-comparator.md)
* **Proposer:** [Marcin Górny](https://github.com/mmagician/)
diff --git a/docs/RFPs/Closed/social-recovery-wallet.md b/docs/RFPs/social-recovery-wallet.md
similarity index 95%
rename from docs/RFPs/Closed/social-recovery-wallet.md
rename to docs/RFPs/social-recovery-wallet.md
index 22cddad44cd..a4ec6d56efb 100644
--- a/docs/RFPs/Closed/social-recovery-wallet.md
+++ b/docs/RFPs/social-recovery-wallet.md
@@ -1,5 +1,9 @@
# Social Recovery Wallet
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented 1](https://github.com/w3f/Grants-Program/blob/master/applications/Plus-social-recovery-wallet.md), [Implemented 2](https://github.com/hypha-dao/hashed-wallet), [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/dauth_network.md)
* **Proposer:** [Noc2](https://github.com/Noc2)
diff --git a/docs/RFPs/Closed/staking-rewards-collector-front-end.md b/docs/RFPs/staking-rewards-collector-front-end.md
similarity index 94%
rename from docs/RFPs/Closed/staking-rewards-collector-front-end.md
rename to docs/RFPs/staking-rewards-collector-front-end.md
index 9a382272ad5..ed1d64a38ca 100644
--- a/docs/RFPs/Closed/staking-rewards-collector-front-end.md
+++ b/docs/RFPs/staking-rewards-collector-front-end.md
@@ -1,5 +1,9 @@
# Front-End for Staking Rewards Collector
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** Implemented: [Repo 1, finished](https://github.com/w3f/Open-Grants-Program/blob/master/applications/cryptolab-staking-reward-collector-front-end.md), [Repo 2, in progress](https://github.com/w3f/Open-Grants-Program/blob/master/applications/staking-rewards-collector-front-end.md)
* **Proposer:** JonasW3F
* **Your Project(s):** -
@@ -10,7 +14,7 @@
The [staking-rewards-collector](https://github.com/w3f/staking-rewards-collector) is a tool to gather staking rewards for given addresses and cross-reference those with daily price data. This is a very useful tool for every validator and nominator in the ecosystem. However, since it has currently a CLI and requires some technical knowledge to set up (git, nodejs, yarn). A front-end hosted on a website could help many users getting access to this tool and enjoy the benefits.
-The backend is already written in javascript, this should make it quite easy to host as a website and develope a front-end.
+The backend is already written in javascript, this should make it quite easy to host as a website and develop a front-end.
## Deliverables :nut_and_bolt:
diff --git a/docs/RFPs/Open/sub-consensus.md b/docs/RFPs/sub-consensus.md
similarity index 95%
rename from docs/RFPs/Open/sub-consensus.md
rename to docs/RFPs/sub-consensus.md
index f2102639099..1221a57cdae 100644
--- a/docs/RFPs/Open/sub-consensus.md
+++ b/docs/RFPs/sub-consensus.md
@@ -1,5 +1,9 @@
# Sub-consensus mechanism
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
* **Status:** Open
* **Proposer:** mmagician, laboon
* **Projects you think this work could be useful for:** All parachains
diff --git a/docs/RFPs/Closed/uncollateralized-stablecoin-research.md b/docs/RFPs/uncollateralized-stablecoin-research.md
similarity index 94%
rename from docs/RFPs/Closed/uncollateralized-stablecoin-research.md
rename to docs/RFPs/uncollateralized-stablecoin-research.md
index 4dde1ba3dcb..d89129c7c8c 100644
--- a/docs/RFPs/Closed/uncollateralized-stablecoin-research.md
+++ b/docs/RFPs/uncollateralized-stablecoin-research.md
@@ -1,5 +1,9 @@
# Uncollateralized Stablecoin Research
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/stardust.md)
* **Proposer:** [Noc2](https://github.com/Noc2)
* **Projects you think this work could be useful for** [optional]: Any Defi Project
@@ -55,6 +59,6 @@ The milestones below are just an initial draft. The milestones can be structured
| Number | Deliverable | Specification |
| ------------- | ------------- | ------------- |
-| 1. | Implement PoC| Implement the previous reasearch as ink! Smart contract or pallets |
+| 1. | Implement PoC| Implement the previous research as ink! Smart contract or pallets |
| 2. | UI (optional) | Implement a basic UI that can be used for testing |
diff --git a/docs/RFPs/Open/uptane-for-substrate-design-and-scope.md b/docs/RFPs/uptane-for-substrate-design-and-scope.md
similarity index 97%
rename from docs/RFPs/Open/uptane-for-substrate-design-and-scope.md
rename to docs/RFPs/uptane-for-substrate-design-and-scope.md
index f419262f612..184174eaf7b 100644
--- a/docs/RFPs/Open/uptane-for-substrate-design-and-scope.md
+++ b/docs/RFPs/uptane-for-substrate-design-and-scope.md
@@ -1,6 +1,10 @@
# Designing Upchain: A framework for securing Substrate software update systems
-* **Status:** Open
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
+* **Status:** Closed
* **Proposer:** taqtiqa-mark
* **Your Project(s):** N.A.
* **Projects you think this work could be useful for** [Substrate runtime upgrades](https://docs.substrate.io/build/upgrade-the-runtime/) and [Substrate network upgrades](https://docs.substrate.io/tutorials/get-started/upgrade-a-running-network/)
diff --git a/docs/RFPs/Open/user-account-access-analysis.md b/docs/RFPs/user-account-access-analysis.md
similarity index 96%
rename from docs/RFPs/Open/user-account-access-analysis.md
rename to docs/RFPs/user-account-access-analysis.md
index 7d2b3d8b6cf..266cc959980 100644
--- a/docs/RFPs/Open/user-account-access-analysis.md
+++ b/docs/RFPs/user-account-access-analysis.md
@@ -1,5 +1,9 @@
# User Account Access Security Analysis for Wallets
+:::tip
+This Request for Proposal is currently _open_, meaning we are actively looking for (additional) teams to apply for it.
+:::
+
* **Status:** Open
* **Proposer:** [Bhargav Bhatt](https://github.com/bhargavbh), [David Hawig](https://github.com/Noc2)
* **Objectives** Security analysis of the user interface of Polkadot Wallets, particularly account access and recovery.
diff --git a/docs/RFPs/Closed/validator-selection-algorithm.md b/docs/RFPs/validator-selection-algorithm.md
similarity index 95%
rename from docs/RFPs/Closed/validator-selection-algorithm.md
rename to docs/RFPs/validator-selection-algorithm.md
index 3402a8bc06a..3a2a3f0edd8 100644
--- a/docs/RFPs/Closed/validator-selection-algorithm.md
+++ b/docs/RFPs/validator-selection-algorithm.md
@@ -1,5 +1,9 @@
# RFP: Validator Selection Algorithm
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Closed](https://github.com/w3f/Grants-Program/blob/master/applications/validators_selection.md)
* **Proposer:** [jonasW3F](https://github.com/jonasW3F)
diff --git a/docs/RFPs/Closed/validator-setup-maintenance.md b/docs/RFPs/validator-setup-maintenance.md
similarity index 91%
rename from docs/RFPs/Closed/validator-setup-maintenance.md
rename to docs/RFPs/validator-setup-maintenance.md
index 7dabd5bfd1f..e46bd88e424 100644
--- a/docs/RFPs/Closed/validator-setup-maintenance.md
+++ b/docs/RFPs/validator-setup-maintenance.md
@@ -1,5 +1,9 @@
# polkadot-validator-setup maintenance
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Closed](https://github.com/polkachu/polkadot-validator)
* **Teams/People that could deliver the RFP:** @melozo, @pmensik, @tylerztl, @bLd75
diff --git a/docs/RFPs/Closed/wallet-aggregator-library.md b/docs/RFPs/wallet-aggregator-library.md
similarity index 89%
rename from docs/RFPs/Closed/wallet-aggregator-library.md
rename to docs/RFPs/wallet-aggregator-library.md
index 15d0437bf09..d441ac92283 100644
--- a/docs/RFPs/Closed/wallet-aggregator-library.md
+++ b/docs/RFPs/wallet-aggregator-library.md
@@ -1,5 +1,9 @@
# Wallet Aggregator Library
+:::danger
+This Request for Proposals is _closed_, meaning we are not looking for any more proposals on this topic at the moment.
+:::
+
* **Status:** [Implemented: SubConnect](https://github.com/Koniverse/SubConnect), [Implemented: talisman-connect](https://github.com/TalismanSociety/talisman-connect)
* **Proposer:** [Matteo Casonato](https://github.com/0xCaso)
@@ -20,4 +24,4 @@ The following items could be the initial deliverables of the project. Of course,
- UI components (connect button, account and chain selector, etc.);
- UI/UX (for both users/devs) **improvement**:
- addition of a tool that scaffolds a new project with the wallet connection library (firable, for example, with `npm init @user/wallet-aggregator@latest`);
- - selective account disclosure implementation (view [this](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Under%20Development/privacy-enhancement-polkadot-extension.md) RFP).
+ - selective account disclosure implementation (view [this](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/privacy-enhancement-polkadot-extension.md) RFP).
diff --git a/docs/RFPs/Open/xcm-tool.md b/docs/RFPs/xcm-tool.md
similarity index 87%
rename from docs/RFPs/Open/xcm-tool.md
rename to docs/RFPs/xcm-tool.md
index d328524adfc..8f13bd41645 100644
--- a/docs/RFPs/Open/xcm-tool.md
+++ b/docs/RFPs/xcm-tool.md
@@ -1,5 +1,9 @@
# XCM library & tools
+:::caution
+This Request for Proposals is currently considered **under development**, meaning one or more grants have been signed to address the topic. We might be interested in additional implementations, but it’s better to double check this with the grants team.
+:::
+
* **Status:** [Implemented](https://github.com/w3f/Grants-Program/blob/master/applications/ParaSpell_follow-up2.md), [Under Development 1](https://github.com/w3f/Grants-Program/blob/master/applications/xcm-tools.md), [Under Development 2](https://github.com/w3f/Grants-Program/blob/master/applications/xcm-domain-service.md)
* **Proposer:** [Bryan Chen](https://github.com/xlc)
* **Projects you think this work could be useful for** : Every parachain.
diff --git a/docs/Support Docs/T&Cs.md b/docs/Support Docs/T&Cs.md
index 8ba6919da9b..d768aa07bda 100644
--- a/docs/Support Docs/T&Cs.md
+++ b/docs/Support Docs/T&Cs.md
@@ -23,8 +23,6 @@ The terms defined in this section whenever used in these Terms and Conditions sh
"Affiliate" has the meaning with respect to any person, any other person directly or indirectly controlling, controlled by or under common control with such person;
-"BTC" means the blockchain tokens native to the Bitcoin Network;
-
"Change of control" means any change in Your ownership or control or of a legal entity directly or indirectly owning or controlling You, whether by merger, consolidation, reorganization, take-over, change in the ownership of the share capital or otherwise;
"Development Work" means any and all development activities related to the Software and undertaken by You. For the avoidance of doubt, any development activities undertaken before the Effective Date in relation to the Software are deemed to constitute Development Work and to form part of the deliverables to be provided by You and be subject to the terms of these Terms and Conditions;
@@ -75,7 +73,7 @@ To apply for the Web 3.0 Foundation Grants Program, your application shall fulfi
- 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 USDT or USDC/DAI on Polkadot AssetHub, fiat or BTC;
+- You must accept payment in USDT or USDC on Polkadot AssetHub or fiat;
- 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:
@@ -123,7 +121,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. 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 bank account, Bitcoin or Polkadot AssetHub (for USDT and USDC) 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 bank account or Polkadot AssetHub (for USDT and USDC) address specified in the initial application.
## 5. Scope of these Terms and Conditions
diff --git a/docs/Support Docs/announcement-guidelines.md b/docs/Support Docs/announcement-guidelines.md
index 445901fdf2b..4bd9c784e9b 100644
--- a/docs/Support Docs/announcement-guidelines.md
+++ b/docs/Support Docs/announcement-guidelines.md
@@ -31,7 +31,7 @@ We also cross-promote the most recent projects and their milestones on Twitter o
3. Why you chose to build on this tech stack
- Illustrate the rationale for the relationship - why did you decide to work with Web3 Foundation?
- Describe the benefits of building on Polkadot, Kusama etc. (shared security, ease of use, ease of deployment, ease of interchain communication, decentralized,
- trusted, etc.) and why it was it important to have these features for your project.
+ trusted, etc.) and why it was important to have these features for your project.
4. Quote
- Your CEO / CTO / Founder may want to include a quote of why they picked Web3 Foundation to help gain more visibility and traction in the market.
5. Description of Web3 Foundation
diff --git a/docs/Support Docs/privacy_policy.md b/docs/Support Docs/privacy_policy.md
index 288db029c0b..79fd344cf34 100644
--- a/docs/Support Docs/privacy_policy.md
+++ b/docs/Support Docs/privacy_policy.md
@@ -1,21 +1,21 @@
Privacy Policy
===========================
-Updated December 2022
+Updated November 2023
## I. Data controller
-1. The operator of the Web 3.0 Foundation website available under [https://w3f.github.io/Grants-Program/](https://w3f.github.io/Grants-Program/) (hereinafter referred to as the "**Website**") and offeror of blockchain-related services (such as currently e.g. the Polkadot Network, the Kusama Network and the Thousand Validators programme (hereinafter jointly and individually referred to as the "**Services**") and, thus, the Data Controller is the Web 3.0 Technologies Foundation, a company registered in the commercial register of the Canton of Zug, Switzerland (registration number CH-322.596.347), with the registered address Baarerstrasse 14, 6300 Zug, Switzerland (hereinafter referred to as "**Controller**", "**we**", "**us**").
-2. We nurture and steward technologies and applications in the fields of decentralized web software protocols, particularly those, which utilize modern cryptographic methods to safeguard decentralization. Data protection is important to us and Controller adheres to the applicable data protection laws and regulations. This includes both the Swiss Federal Act on Data Protection ("**FADP**") and privacy requirements where applicable to individuals in the European Union and the member states of EFTA under the General Data Protection Regulation (hereinafter "**GDPR**") and/or other applicable national laws.
-3. This Privacy Policy explains in particular how, for which purposes and to which extent your Personal Data is collected and processed by us through the Website or any type of Service we provide to you (whenever we are referring to you, hereinafter referred to as "**User**" or "**you**"). It also describes how your collected Personal Data can be verified, corrected or deleted. Our Services enable the collection of your Personal Data necessary for the establishment and maintenance of our blockchain-offerings.C
+1. The operator of the Web 3.0 Foundation website available under [https://grants.web3.foundation/](https://grants.web3.foundation/) (hereinafter referred to as the "**Website**") and offeror of blockchain-related services (such as currently e.g. the Polkadot Network, the Kusama Network and the Thousand Validators programme (hereinafter jointly and individually referred to as the "**Services**") and, thus, the Data Controller is the Web 3.0 Technologies Foundation, a company registered in the commercial register of the Canton of Zug, Switzerland (registration number CH-322.596.347), with the registered address Baarerstrasse 14, 6300 Zug, Switzerland (hereinafter referred to as "**Controller**", "**we**", "**us**").
+2. We nurture and steward technologies and applications in the fields of decentralized web software protocols, particularly those which utilize modern cryptographic methods to safeguard decentralization. Data protection is important to us, and the Controller adheres to the applicable data protection laws and regulations. This includes both the Swiss Federal Act on Data Protection ("**FADP**") and privacy requirements where applicable to individuals in the European Union and the member states of EFTA under the General Data Protection Regulation (hereinafter "**GDPR**") and/or other applicable national laws.
+3. This Privacy Policy explains in particular how, for which purposes and to which extent your Personal Data is collected and processed by us through the Website or any type of Service we provide to you (whenever we are referring to you, hereinafter referred to as "**User**" or "**you**"). It also describes how your collected Personal Data can be verified, corrected or deleted. Our Services enable the collection of your Personal Data necessary for the establishment and maintenance of our blockchain-offerings.
4. As outlined in Sections II and X.A below, if you engage with us and use any of our blockchain-offerings, we may collect, by itself or through third parties, your data including, but not limited to: name, e-mail address, usage data and any information captured automatically through cookies. Complete details on each type of Personal Data collected are provided in the dedicated sections of this Privacy Policy or by specific explanation displayed to you online prior to the data collection.
-5. This Website contains links to other third party websites. If you follow a link to any of those third party websites, please note that they have their own privacy policies and that we do not accept any responsibility or liability for their policies or their processing of your personal information.
-6. For questions or requests related to data processing by us (such as request for information, deletion, revocation of consent, objection to data processing), you may revert by mail to the address above or write us an e-mail at [legal@web3.foundation](mailto:legal@web3.foundation)
+5. This Website contains links to other third-party websites. If you follow a link to any of those third-party websites, please note that they have their own privacy policies and that we do not accept any responsibility or liability for their policies or their processing of your personal information.
+6. For questions or requests related to data processing by us (such as request for information, deletion, revocation of consent, or objection to data processing), you may revert by mail to the address above or write us an e-mail at [legal@web3.foundation](mailto:legal@web3.foundation)
## II. Types of Data collected
-1. Controller respects the privacy of the User and will not collect and process any other data (such as name, address, phone number, e-mail address, IP address, device type etc.) unless they are
+1. The Controller respects the privacy of the User and will not collect and process any other data (such as name, address, phone number, e-mail address, IP address, device type, etc.) unless they are
* provided voluntarily by the User;
* gathered as a result of specific verifications performed by third parties included in Section X.C below based on the Personal Data provided by the User;
@@ -26,12 +26,12 @@ Updated December 2022
### A. Use of Personal Data
-1. Data transmitted by the User to Controller may be used as follows:
+1. Data transmitted by the User to the Controller may be used as follows:
* to create a user account;
* to respond to your inquiries and your correspondence;
- * for marketing analysis purposes, in particular to better understand the needs of Users and improve the Services of Controller, and to provide Users with relevant information relating to any of our networks operated;
- * to ensure our Website functions correctly, in particular to ensure that content from our Website is presented in the most effective manner for you and for your computer;
+ * for marketing analysis purposes, in particular, to better understand the needs of Users and improve the Services of Controller, and to provide Users with relevant information relating to any of our networks operated;
+ * to ensure our Website functions correctly, in particular, to ensure that content from our Website is presented in the most effective manner for you and for your computer;
* to maintain or improve our services offered through the Website.
2. Please consult Section XI below to get further information on additional use of your data collected on any of our network offerings.
@@ -39,20 +39,20 @@ Updated December 2022
1. The Controller may process Personal Data of Users if one of the following applies:
- 1. Users have given their consent for one or more specific purposes. Note: Under some legislations, the Controller may be allowed to process Personal Data until the User objects to such processing ("opt-out"), without having to rely on consent or any other of the following legal bases. This, however, does not apply, whenever the processing of Personal Data is subject to European data protection law (GDPR);
+ 1. Users have given their consent for one or more specific purposes. Note: Under some legislations, the Controller may be allowed to process Personal Data until the User objects to such processing ("opt-out") without having to rely on consent or any other of the following legal bases. This, however, does not apply, whenever the processing of Personal Data is subject to European data protection law (GDPR);
2. provision of Data is necessary for the performance of an agreement with the User and/or for any pre-contractual obligations thereof;
3. processing is necessary for the establishment, exercise or defence of legal claims or proceedings;
4. processing is necessary for compliance with a legal and regulatory obligation to which the Controller is subject;
5. processing is related to a task that is carried out in the public interest or in the exercise of official authority vested in the Controller;
6. processing is necessary for the purposes of the legitimate interests pursued by the Controller or by a third party.
-2. In any case, the Controller will gladly help to clarify the specific legal basis that applies to the processing, and in particular whether the provision of Personal Data is a statutory or a contractual requirement, or a requirement necessary to enter into a contract.
+2. In any case, the Controller will gladly help to clarify the specific legal basis that applies to the processing, and in particular whether the provision of Personal Data is a statutory or a contractual requirement or a requirement necessary to enter into a contract.
3. Within and to the extent under the scope of application of the GDPR, the data processing described in this clause III. is justified in order to provide our contractually agreed services to you pursuant to Art. 6 para. 1 sentence 1 letter b GDPR and to comply with legal obligations to which we are subject pursuant to Art. 6 para. 1 letter c GDPR.
### C. Methods of processing, access to data and disclosure to third parties
-1. The data processing is carried out using computers and/or IT enabled tools, following organizational procedures and modes strictly related to the purposes indicated.
-2. Access to Personal Data is limited to those employees and/or third parties assigned with processing tasks who therefore need to know about this data. These employees and/or third parties are subject to confidentiality undertakings and/or data processing agreements and must comply with applicable data protection laws.
-3. Controller does not sell, transfer or market your Personal Data to third parties (who may use them for their own purposes). However, we may disclose your Personal Data to trusted third parties and/or certain types of persons in charge, involved with the operation of this Website (administration, sales, marketing, legal, system administration) or external parties (such as third party technical service providers, mail carriers, hosting providers, IT companies, communications agencies, our auditors, third parties involved in hosting or organizing events or seminars) appointed, if necessary, as Data Processors by the Controller.
+1. The data processing is carried out using computers and/or IT-enabled tools, following organizational procedures and modes strictly related to the purposes indicated.
+2. Access to Personal Data is limited to those employees and/or third parties assigned with processing tasks who therefore, need to know about this data. These employees and/or third parties are subject to confidentiality undertakings and/or data processing agreements and must comply with applicable data protection laws.
+3. Controller does not sell, transfer or market your Personal Data to third parties (who may use them for their own purposes). However, we may disclose your Personal Data to trusted third parties and/or certain types of persons in charge involved with the operation of this Website (administration, sales, marketing, legal, system administration) or external parties (such as third party technical service providers, mail carriers, hosting providers, IT companies, communications agencies, our auditors, third parties involved in hosting or organizing events or seminars) appointed, if necessary, as Data Processors by the Controller.
4. Please consult Section XI below for lists of all third party processors currently assigned with processing activities on our behalf on any of our networks operated.
5. Your Personal Data will not be disclosed to third parties for other purposes than the ones mentioned above or the following additional reasons:
@@ -64,23 +64,23 @@ Updated December 2022
### D. Place of processing and export of data
1. The data is processed at the Controller's operating offices and in any other places where the parties involved in the processing are located. Depending on the User's location, data transfers may involve transferring the User's data to a country other than their own.
-2. Therefore, we reserve the right to transfer, store, use and process your data, including any personal information, to/by recipients in countries outside of the European Economic Area ("**EEA**") including the United States and possibly other countries. You should note that laws vary from jurisdiction to jurisdiction, and so laws and regulations relating to privacy and data disclosure, applicable to the places where your information is transferred to or stored, used or processed in, may not provide the same level of protection as in your place of residency. We take the legally required safeguards and contractual measures to ensure that any recipients of your Personal Data abroad undertake to comply with the level of data protection and security prescribed by your applicable local data protection legislation.
+2. Therefore, we reserve the right to transfer, store, use and process your data, including any personal information, to/by recipients in countries outside of the European Economic Area ("**EEA**") including the United States and possibly other countries. You should note that laws vary from jurisdiction to jurisdiction, and so laws and regulations relating to privacy and data disclosure applicable to the places where your information is transferred to or stored, used or processed in, may not provide the same level of protection as in your place of residency. We take the legally required safeguards and contractual measures to ensure that any recipients of your Personal Data abroad undertake to comply with the level of data protection and security prescribed by your applicable local data protection legislation.
## IV. Retention of data
-1. The Controller will retain Personal Data for as long as it is required to deliver the Services described in Sections III.A above and X.B below, and/or, upon termination, as long as required by law or regulations (e.g. mandatory retention periods), whichever is longer.
+1. The Controller will retain Personal Data for as long as it is required to deliver the Services described in Sections III. A above and X.B below, and/or, upon termination, as long as required by law or regulations (e.g. mandatory retention periods), whichever is longer.
Therefore,
1. Personal Data collected for purposes related to the performance of a contract between the Controller and the User shall be retained until such contract has been fully performed;
2. Personal Data collected for the purposes of the Controller's legitimate interests shall be retained as long as needed to fulfil such purposes.
2. The Controller may be allowed to retain Personal Data for a longer period whenever the User has given consent to such processing, as long as such consent is not withdrawn.
-3. Once the retention period expires, Personal Data shall be deleted. Therefore, the right to access, the right to erasure, the right to rectification and the right to data portability cannot be enforced after expiration of the retention period.
+3. Once the retention period expires, Personal Data shall be deleted. Therefore, the right to access, the right to erasure, the right to rectification and the right to data portability cannot be enforced after the expiration of the retention period.
## V. Security measures
1. We take adequate technical and organizational precautions and security measures to prevent accidental or intentional manipulation, unauthorized access, disclosure, unauthorized destruction, partial or complete loss, misuse or alteration of your Personal Data. Accordingly, we store all the personal information you provide on secure (password- and firewall-protected) servers. Our security measures are continuously improved in line with technical developments. You are responsible for keeping the account information for accessing any of our networks operated confidential.
-2. The User is aware and acknowledges that no technical and organizational measures can fully eliminate security risks connected with transmission of information over the Internet. Once Controller has received the transmitted information, it shall adequately secure it in its systems.
+2. The User is aware and acknowledges that no technical and organizational measures can fully eliminate security risks connected with the transmission of information over the Internet. Once the Controller has received the transmitted information, it shall adequately secure it in its systems.
## VI. The rights of Users
@@ -90,7 +90,7 @@ Updated December 2022
* Withdraw their consent at any time. Users have the right to withdraw consent where they have previously given their consent to the processing of their Personal Data. Please note that even after you have chosen to withdraw your consent, we may be able to continue to process your Personal Data to the extent required or permitted by law.
* Object to processing of their data. Users have the right to object to the processing of their data if the processing is carried out on a legal basis other than consent (e.g. for a public interest, in the exercise of an official authority vested in the Controller or for the purpose of legitimate interests pursued by the Controller). Users may object to such processing by providing a ground related to their particular situation to justify the objection. In particular, under and to the extent of a scope of application of the GDPR, in those cases where we base processing on our legitimate interests, you have the right to object to the processing. Users must know that, however, should their Personal Data be processed for direct marketing purposes, they can object to that processing at any time without providing any justification.
- * Access their data. Users have the right to learn if the Controller is processing data, obtain disclosure regrading certain aspects of the processing and obtain a copy of the data undergoing processing.
+ * Access their data. Users have the right to learn if the Controller is processing data, obtain disclosure regarding certain aspects of the processing and obtain a copy of the data undergoing processing.
* Verify and seek rectification. Users have the right to verify the accuracy of their data and ask for it to be updated or corrected. Please note that you must advise us of any changes to your personal information so that we can ensure that your personal information is accurate and up to date.
* Restrict the processing of their data. Users have the right, under certain circumstances, to restrict the processing of their data if the accuracy of the data is disputed. In this case, the Controller will not process their data for any purpose other than storing it.
* Restrict the use of Personal Data whilst complaints are resolved.
@@ -99,7 +99,7 @@ Updated December 2022
* Receive their data and have it transferred to another controller. Users have the right to receive their data in a structured, commonly used and machine readable format and, if technically feasible, to have it transmitted to another controller without any hindrance. This provision is applicable provided that the data is processed by automated means and that the processing is based on the User's consent, on a contract which the User is part of or on pre-contractual obligations thereof.
* Lodge a complaint. Users have the right to bring a claim before their competent data protection authority (depending on your country of residence and the applicable data protection laws – note that in certain countries you may only notify a data protection authority which may then decide to initiate legal steps based on its own discretion).
2. Any requests to exercise User rights can be directed to the Controller through the contact details provided in this document.
-3. Where possible, Controller will fulfil such a request of the User within the statutory applicable timeframe, unless a delay or a retention of the relevant data is permitted by law (e.g. a lack of convincing identity proof by an information requestor), is required for another valid purpose, for example to enable the fulfilment of contractual obligations, or is covered by a valid limitation or exemption under relevant privacy or data protection regulations.
+3. Where possible, the Controller will fulfil such a request of the User within the statutory applicable timeframe, unless a delay or a retention of the relevant data is permitted by law (e.g. a lack of convincing identity proof by an information requestor), is required for another valid purpose, for example, to enable the fulfilment of contractual obligations, or is covered by a valid limitation or exemption under relevant privacy or data protection regulations.
4. Any requests will be free of charge, provided we do not incur unexpected and inadequate costs for providing you with details of your Personal Data.
## VII. Cookies
@@ -107,7 +107,7 @@ Updated December 2022
1. When the User visits the Website, information can be automatically stored on his or her computer. This is done in the form of so-called "cookies" or a similar file, which help Controller in various ways, for example, to get to know the preferences of visitors and Users of the Website and to improve the Website. Both permanent cookies and functional, temporary session cookies may be used: permanent cookies remain on your computer after you close your session and until you delete them, while session cookies expire when you close your browser.
2. Any use of Cookies – or of other tracking tools – by this Website or by the Controller of third-party services used by this Website serves the purpose of providing the Service required by the User, in addition to any other purposes described in the present document and in the Cookie Notice, if available. Please consult Section XI below to get information on any Cookie Notices available on any of our networks operated.
3. You may refuse the use of any cookies by selecting the appropriate settings on your browser. Most browsers allow you to delete cookies, prevent their installation or generate a warning before a cookie is installed. The User can obtain further information on this subject from the relevant browser instructions. Note, however, that this may affect your experience of our Website. To find out more about cookies, including how to manage, reject and delete cookies, visit [www.allaboutcookies.org](https://www.google.com/url?q=http://www.allaboutcookies.org&sa=D&ust=1593180898892000).
-4. Controller will use automatically stored information exclusively for statistical analysis and in particular will not associate any Personal Data with the User unless necessary. This Notice does not limit our use or disclosure to third parties of Non-Personal Information, and we reserve the right to use and disclose such Non-Personal Information to our partners, advertisers, and other third parties at our discretion.
+4. Controller will use automatically stored information exclusively for statistical analysis and in particular, will not associate any Personal Data with the User unless necessary. This Notice does not limit our use or disclosure to third parties of Non-Personal Information, and we reserve the right to use and disclose such Non-Personal Information to our partners, advertisers, and other third parties at our discretion.
5. Within and to the extent under the scope of application of the GDPR, the data processed by cookies for the aforementioned purposes is justified in order to protect our legitimate interest and those of third parties pursuant to Art. 6 para. 1 sentence 1 letter f GDPR.
6. *Simple Analytics*. Even if we don't need to disclose it, since we aim to be as much transparent as possible with our users, we inform you that to get information about the behaviour of our user, we use Simple Analytics (). This analytics software gives us insight about our user only in general, but not about individuals, as it does not track visitors and does not store any personal identifiable information. If you would like to, please go to their website to find out what Simple Analytics collects (and most importantly what they don’t).
@@ -118,9 +118,9 @@ Updated December 2022
## IX. Access to the Privacy Policy
-1. The User can access, download, save or print this Privacy Policy in its' current/updated version at any time under the following address [https://web3.foundation/privacy-and-cookies/](https://web3.foundation/privacy-and-cookies).
+1. The User can access, download, save or print this Privacy Policy in its current/updated version at any time under the following address [https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/privacy_policy.md](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/privacy_policy.md).
-## IX. Definitions and legal references
+## X. Definitions and legal references
1. **Personal Data**
@@ -142,7 +142,7 @@ Updated December 2022
The natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of Personal Data, including the security measures concerning the operation and use of this Website. The Data Controller, unless otherwise specified, is the owner of this Website.
7. **Website**
- The Website of Controller available under [https://w3f.github.io/Grants-Program/](https://w3f.github.io/Grants-Program/).
+ The Website of the Controller is available under [https://w3f.github.io/Grants-Program/](https://w3f.github.io/Grants-Program/).
8. **Service**
The Services (and blockchain offerings) provided by Controller.
@@ -151,7 +151,7 @@ Updated December 2022
Unless otherwise specified, all references made within this document to the European Union include all current member states to the European Union and the European Economic Area.
10. **Cookies**
- Small sets of data stored in the User's device.
+ Small sets of data are stored in the User's device.
11. **Legal information**
This privacy statement has been prepared based on provisions of multiple legislations, including Art. 13/14 of Regulation (EU) 2016/679 (General Data Protection Regulation).
diff --git a/docs/contribute.md b/docs/contribute.md
index 602699a8651..707b41a7631 100644
--- a/docs/contribute.md
+++ b/docs/contribute.md
@@ -5,10 +5,10 @@ title: 🫶 Contribute
The W3F Grants Program aims to be as open and accessible as possible. If you are interested in contributing or getting involved, there are several ways you can do that:
-📋 We are open to milestone evaluations from third parties. If you are particularly interested in a certain project, or particularly knowledgeable on a relevant subject, feel free to comment on any [open grant applications](https://github.com/w3f/Grants-Program/issues?q=is%3Aopen+label%3A%22ready+for+review%22+sort%3Aupdated-desc), or have a look at the [open pull requests on our milestone delivery repository](https://github.com/w3f/Grant-Milestone-Delivery/pulls) and [submit your own evaluation](https://github.com/w3f/Grant-Milestone-Delivery#ballot_box_with_check-external-evaluations).
+- 📋 We are open to **milestone evaluations** from third parties. If you are particularly interested in a certain project, or particularly knowledgeable on a relevant subject, feel free to comment on any [open grant applications](https://github.com/w3f/Grants-Program/issues?q=is%3Aopen+label%3A%22ready+for+review%22+sort%3Aupdated-desc), or have a look at the [open pull requests on our milestone delivery repository](https://github.com/w3f/Grant-Milestone-Delivery/pulls) and [submit your own evaluation](https://github.com/w3f/Grant-Milestone-Delivery#ballot_box_with_check-external-evaluations).
-🔍 If you find that there is something missing in our ecosystem (a tool, a project, infrastructure, etc.) that we could help fund, please [submit a Request For Proposals (RFP)](https://github.com/w3f/Grants-Program/blob/master/README.md#mailbox_with_mail-suggest-a-project). If writing an RFP seems too daunting a task, feel free to [submit it as an issue on our Github repository](https://github.com/w3f/Grants-Program/issues) so anyone can contribute.
+- 🔍 If you find that there is something missing in our ecosystem (a tool, a project, infrastructure, etc.) that we could help fund, please [submit a **Request For Proposals (RFP)**](https://github.com/w3f/Grants-Program/blob/master/README.md#mailbox_with_mail-suggest-a-project). If writing an RFP seems too daunting a task, feel free to [submit it as an issue on our Github repository](https://github.com/w3f/Grants-Program/issues) so anyone can contribute.
-🤝 Join us! We are looking for a Technical Grants Evaluator (among other things) to join us full time. Check out [our current job openings](https://web3.bamboohr.com/jobs/) and apply!
+- 🤝 Join us! Check out [our current **job openings**](https://web3.bamboohr.com/jobs/) and apply! If there currently is no suitable job listed, don't hesitate to apply regardless or [reach out](./help.md) if you have any questions.
We strive to continue improving our grants program and are always open to feedback. If you would like to share any suggestions or criticism, please reach out to us on [Github](https://github.com/w3f/Grants-Program) or [Matrix](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org)!
diff --git a/docs/faq.md b/docs/faq.md
index 7e56fc13656..9ad600453a3 100644
--- a/docs/faq.md
+++ b/docs/faq.md
@@ -68,6 +68,10 @@ title: 🙋 FAQ
Our [application template](https://github.com/w3f/Grants-Program/blob/e03a3e760846bfaf44352cb17a6763ff0fcf1a94/.github/pull_request_template.md?plain=1#L21) also offers the possibility to make the application public, but to keep its discussion private.
+### What is KYC/KYB and why do I have to provide this data?
+
+ In order to comply with regulations, the Web3 Foundation is required to perform KYC (Know Your Customer) checks on individuals and KYB (Know Your Business) checks on entities applying for a grant in order to verify their identity. For these checks, we ask you to provide information about yourself and/or the entity you are representing through our provider [Sumsub](https://sumsub.com/). If you have any problems with or concerns about this process, please [reach out to us](mailto:grants@web3.foundation).
+
## 🥳 After Approval
### When can I apply for a follow-up grant?
diff --git a/docs/funding.md b/docs/funding.md
index 54a3977aa63..3eaad1f6a88 100644
--- a/docs/funding.md
+++ b/docs/funding.md
@@ -31,8 +31,10 @@ Below is a list of other grant and bounty programs in the Polkadot/Substrate eco
- [Acala Grants Program](https://acala.network/ecosystem-program)
- [Aleph Zero Funding Program](https://alephzero.org/ecosystem-funding-program)
- [Astar / Shiden Network Builders Program](https://github.com/PlasmNetwork/Builders-Program)
+- [Avail Uncharted Grants](https://github.com/availproject/avail-uncharted/blob/main/grants/grants.md)
- [Crust Grants Program](https://github.com/crustio/Crust-Grants-Program)
- [Darwinia Grants Program](https://github.com/darwinia-network/collaboration/blob/master/grant/README.md#grant-program)
+- [Decentralized Futures Program](https://futures.web3.foundation/)
- [Edgeware Grants and Bounties](https://gov.edgewa.re/discussion/1132-edgeware-proposal-process-and-template)
- [HydraDX Grants and Bounties](https://docs.hydradx.io/spending_fw/)
- [ink!ubator](https://use.ink/ubator/)
diff --git a/docs/referral-program.md b/docs/referral-program.md
index 5bce2450643..d4fcdf3b8eb 100644
--- a/docs/referral-program.md
+++ b/docs/referral-program.md
@@ -5,4 +5,4 @@ title: 💰 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](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md)). Payment is made in Bitcoin or USDT/USDC on Polkadot AssetHub.
+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](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md)). Payment is made in USDT/USDC on Polkadot AssetHub.
diff --git a/docs/rfps.md b/docs/rfps.md
index 5348ab55b13..5237c46174e 100644
--- a/docs/rfps.md
+++ b/docs/rfps.md
@@ -23,15 +23,12 @@ If you find an open RFP here that you think you can address, feel free to [submi
| RFP | Last Updated |
| :-- | :----------: |
-| [anti-collusion_infrastructure.md](RFPs/Open/anti-collusion_infrastructure.md) | 21.09.2023 |
-| [formal_guarantees_for_grandpa.md](RFPs/Open/formal_guarantees_for_grandpa.md) | 07.10.2022 |
-| [ISO_20022.md](RFPs/Open/ISO_20022.md) | 20.09.2023 |
-| [parachain_validation_conformance_testing.md](RFPs/Open/parachain_validation_conformance_testing.md) | 18.01.2023 |
-| [polkadot-protocol_conformance_tests.md](RFPs/Open/polkadot-protocol_conformance_tests.md) | 21.09.2023 |
-| [sub-consensus.md](RFPs/Open/sub-consensus.md) | 23.02.2022 |
-| [uptane-for-substrate-design-and-scope.md](RFPs/Open/uptane-for-substrate-design-and-scope.md) | 04.03.2023 |
-| [user-account-access-analysis.md](RFPs/Open/user-account-access-analysis.md) | 07.01.2023 |
-| [xcm-tool.md](RFPs/Open/xcm-tool.md) | 21.09.2023 |
+| [anti-collusion_infrastructure.md](RFPs/anti-collusion_infrastructure.md) | 21.09.2023 |
+| [formal_guarantees_for_grandpa.md](RFPs/formal_guarantees_for_grandpa.md) | 12.10.2023 |
+| [ISO_20022.md](RFPs/ISO_20022.md) | 12.10.2023 |
+| [parachain_validation_conformance_testing.md](RFPs/parachain_validation_conformance_testing.md) | 18.01.2023 |
+| [sub-consensus.md](RFPs/sub-consensus.md) | 23.02.2022 |
+| [user-account-access-analysis.md](RFPs/user-account-access-analysis.md) | 07.01.2023 |
@@ -39,23 +36,21 @@ If you find an open RFP here that you think you can address, feel free to [submi
| RFP | Last Updated |
| :-- | :----------: |
-| [alternative_polkadot_host_implementations.md](RFPs/Under%20Development/alternative_polkadot_host_implementations.md) | 02.03.2023 |
-| [alternative-polkadot-js-api-console.md](RFPs/Under%20Development/alternative-polkadot-js-api-console.md) | 19.05.2023 |
-| [analysis-website-and-data-platform.md](RFPs/Under%20Development/analysis-website-and-data-platform.md) | 21.09.2023 |
-| [data_analysis_tools.md](RFPs/Under%20Development/data_analysis_tools.md) | 21.09.2023 |
-| [decentralized-security-marketplace.md](RFPs/Under%20Development/decentralized-security-marketplace.md) | 25.09.2023 |
-| [grant_management_webapp.md](RFPs/Under%20Development/grant_management_webapp.md) | 25.09.2023 |
-| [identity-directory.md](RFPs/Under%20Development/identity-directory.md) | 20.09.2023 |
-| [IDE_for_ink_Smart_Contracts.md](RFPs/Under%20Development/IDE_for_ink_Smart_Contracts.md) | 20.09.2023 |
-| [implementation-benchmarking.md](RFPs/Under%20Development/implementation-benchmarking.md) | 20.09.2023 |
-| [ink!_smart_contract_block_explorer.md](RFPs/Under%20Development/ink_smart_contract_block_explorer.md) | 20.09.2023 |
-| [ISO_8583.md](RFPs/Under%20Development/ISO_8583.md) | 20.09.2023 |
-| [move_smart_contract_pallet.md](RFPs/Under%20Development/move_smart_contract_pallet.md) | 02.08.2023 |
-| [multi-chain-block-explorer.md](RFPs/Under%20Development/multi-chain-block-explorer.md) | 23.11.2021 |
-| [privacy-enhancement-polkadot-extension.md](RFPs/Under%20Development/privacy-enhancement-polkadot-extension.md) | 27.05.22 |
-| [raft-validators.md](RFPs/Under%20Development/raft-validators.md) | 23.05.2023 |
-| [scale-codec-comparator.md](RFPs/Under%20Development/scale-codec-comparator.md) | 30.05.2022 |
-| [Static-Analysis-for-Runtime-Pallets.md](RFPs/Under%20Development/Static-Analysis-for-Runtime-Pallets.md) | 05.07.2023 |
+| [alternative_polkadot_host_implementations.md](RFPs/alternative_polkadot_host_implementations.md) | 02.03.2023 |
+| [analysis-website-and-data-platform.md](RFPs/analysis-website-and-data-platform.md) | 21.09.2023 |
+| [data_analysis_tools.md](RFPs/data_analysis_tools.md) | 21.09.2023 |
+| [decentralized-security-marketplace.md](RFPs/decentralized-security-marketplace.md) | 25.09.2023 |
+| [identity-directory.md](RFPs/identity-directory.md) | 20.09.2023 |
+| [IDE_for_ink_Smart_Contracts.md](RFPs/IDE_for_ink_Smart_Contracts.md) | 20.09.2023 |
+| [implementation-benchmarking.md](RFPs/implementation-benchmarking.md) | 20.09.2023 |
+| [ink!_smart_contract_block_explorer.md](RFPs/ink_smart_contract_block_explorer.md) | 20.09.2023 |
+| [ISO_8583.md](RFPs/ISO_8583.md) | 20.09.2023 |
+| [jsonrpsee-proxy-support.md](RFPs/jsonrpsee-proxy-support.md) | 06.11.2023 |
+| [move_smart_contract_pallet.md](RFPs/move_smart_contract_pallet.md) | 02.08.2023 |
+| [polkadot-protocol_conformance_tests.md](RFPs/polkadot-protocol_conformance_tests.md) | 21.09.2023 |
+| [raft-validators.md](RFPs/raft-validators.md) | 23.05.2023 |
+| [Static-Analysis-for-Runtime-Pallets.md](RFPs/Static-Analysis-for-Runtime-Pallets.md) | 27.09.2023 |
+| [xcm-tool.md](RFPs/xcm-tool.md) | 21.09.2023 |
@@ -64,26 +59,32 @@ If you find an open RFP here that you think you can address, feel free to [submi
| RFP | Last Updated |
| :-- | :----------: |
-| [a-and-v-topology.md](RFPs/Closed/a-and-v-topology.md) | 04.09.2023 |
-| [appi.md](RFPs/Closed/appi.md) | 20.07.2021 |
-| [bpf-contracts.md](RFPs/Open/bpf-contracts.md) | 06.01.2023 |
-| [candle-auction.md](RFPs/Closed/candle-auction.md) | 02.02.2022 |
-| [crowdloan_front_end_template.md](RFPs/Closed/crowdloan_front_end_template.md) | 25.04.2023 |
-| [epassport-zk-validation.md](RFPs/Closed/epassport-zk-validation.md) | 21.03.2023 |
-| [ksm-tipping-button.md](RFPs/Closed/ksm-tipping-button.md) | 20.07.2021 |
-| [on-chain-quadratic-funding.md](RFPs/Closed/on-chain-quadratic-funding.md) | 29.03.2022 |
-| [php-api.md](RFPs/Closed/php-api.md) | 27.05.2022 |
-| [php-scale.md](RFPs/Closed/php-scale.md) | 23.11.2022 |
-| [polkadot-collator-setup.md](RFPs/Closed/polkadot-collator-setup.md) | 22.03.2023 |
-| [social-recovery-wallet.md](RFPs/Closed/social-recovery-wallet.md) | 03.03.2023 |
-| [staking-rewards-collector-front-end.md](RFPs/Closed/staking-rewards-collector-front-end.md) | 20.07.2021 |
-| [uncollateralized-stablecoin-research.md](RFPs/Closed/uncollateralized-stablecoin-research.md) | 01.01.2023 |
-| [validator-selection-algorithm.md](RFPs/Under%20Development/validator-selection-algorithm.md) | 25.09.2023 |
-| [validator-setup-maintenance.md](RFPs/Closed/validator-setup-maintenance.md) | 24.08.2023 |
-| [wallet-aggregator-library.md](RFPs/Closed/wallet-aggregator-library.md) | 09.03.2023 |
+| [a-and-v-topology.md](RFPs/a-and-v-topology.md) | 04.09.2023 |
+| [alternative-polkadot-js-api-console.md](RFPs/alternative-polkadot-js-api-console.md) | 19.05.2023 |
+| [appi.md](RFPs/appi.md) | 20.07.2021 |
+| [bpf-contracts.md](RFPs/bpf-contracts.md) | 06.01.2023 |
+| [candle-auction.md](RFPs/candle-auction.md) | 02.02.2022 |
+| [crowdloan_front_end_template.md](RFPs/crowdloan_front_end_template.md) | 25.04.2023 |
+| [epassport-zk-validation.md](RFPs/epassport-zk-validation.md) | 21.03.2023 |
+| [grant_management_webapp.md](RFPs/grant_management_webapp.md) | 25.09.2023 |
+| [ksm-tipping-button.md](RFPs/ksm-tipping-button.md) | 20.07.2021 |
+| [multi-chain-block-explorer.md](RFPs/multi-chain-block-explorer.md) | 27.09.2023 |
+| [on-chain-quadratic-funding.md](RFPs/on-chain-quadratic-funding.md) | 29.03.2022 |
+| [php-api.md](RFPs/php-api.md) | 27.05.2022 |
+| [php-scale.md](RFPs/php-scale.md) | 23.11.2022 |
+| [polkadot-collator-setup.md](RFPs/polkadot-collator-setup.md) | 22.03.2023 |
+| [privacy-enhancement-polkadot-extension.md](RFPs/privacy-enhancement-polkadot-extension.md) | 27.09.2023 |
+| [scale-codec-comparator.md](RFPs/scale-codec-comparator.md) | 27.09.2023 |
+| [social-recovery-wallet.md](RFPs/social-recovery-wallet.md) | 03.03.2023 |
+| [staking-rewards-collector-front-end.md](RFPs/staking-rewards-collector-front-end.md) | 20.07.2021 |
+| [uncollateralized-stablecoin-research.md](RFPs/uncollateralized-stablecoin-research.md) | 01.01.2023 |
+| [uptane-for-substrate-design-and-scope.md](RFPs/uptane-for-substrate-design-and-scope.md) | 04.03.2023 |
+| [validator-selection-algorithm.md](RFPs/validator-selection-algorithm.md) | 25.09.2023 |
+| [validator-setup-maintenance.md](RFPs/validator-setup-maintenance.md) | 24.08.2023 |
+| [wallet-aggregator-library.md](RFPs/wallet-aggregator-library.md) | 09.03.2023 |
## 📬 Suggest an RFP
-If you think that we should support the development of certain tools or projects (related to **Polkadot, Kusama or Substrate**) that aren't in the Polkadot/Kusama [tech stack](https://wiki.polkadot.network/docs/build-open-source), please submit a suggestion using the process described in our [Grants program README](suggesting.md). We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem.
+If you think that we should support the development of certain tools or projects (related to **Polkadot, Kusama or Substrate**) that aren't in the Polkadot/Kusama [tech stack](https://wiki.polkadot.network/docs/build-open-source), please submit a suggestion using the process described [here](suggesting.md). We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem.
diff --git a/docusaurus.config.js b/docusaurus.config.js
index e606f27f0bb..726e753053c 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -28,7 +28,7 @@ module.exports = {
announcementBar: {
id: 'announcement',
content:
- 'Meet us at sub0!',
+ 'Check out our newly created Decentralized Futures Program!',
backgroundColor: '#000',
textColor: '#ffffff',
isCloseable: true,
diff --git a/src/components/HomepageFeatures.js b/src/components/HomepageFeatures.js
index bf4ab04dd8b..c81291d1be9 100644
--- a/src/components/HomepageFeatures.js
+++ b/src/components/HomepageFeatures.js
@@ -13,14 +13,14 @@ const FeatureList = [
),
},
{
- title: 550,
+ title: 600,
description: (
<>projects funded
),
},
{
- title: 50,
+ title: 54,
description: (
<>countries
diff --git a/src/css/custom.css b/src/css/custom.css
index 4919a1b86a7..af3e3a89d65 100644
--- a/src/css/custom.css
+++ b/src/css/custom.css
@@ -167,3 +167,10 @@ a:hover.navbar__item{
border-left: 5px solid rgb(0, 0, 0);
background-color: rgba(0, 255, 0, 0.15);
}
+
+/* Border around details */
+details {
+ border: 1px solid;
+ border-radius: 4px;
+ padding: 10px;
+}
\ No newline at end of file