diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index b8eacc22228..7e0cb4664e2 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -14,7 +14,7 @@ - [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). - [ ] 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/README.md b/README.md index 550b5d50fa2..b224a2d81ac 100644 --- a/README.md +++ b/README.md @@ -90,11 +90,9 @@ In cases where a niche expert opinion is desirable, one of the committee members - [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 +103,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 +112,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 +142,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 +217,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 after delivery and approval of the first milestone. +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 @@ -322,6 +317,7 @@ Below is a list of other grant and bounty programs in the Polkadot/Substrate eco - [Astar / Shiden Network Builders Program](https://github.com/PlasmNetwork/Builders-Program) - [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/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/Deitos_Network.md b/applications/Deitos_Network.md new file mode 100644 index 00000000000..7fbc4fa6c02 --- /dev/null +++ b/applications/Deitos_Network.md @@ -0,0 +1,301 @@ +# 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 + +![msg1154506685-35640](https://github.com/Deitos-Network/Grants-Program/assets/1779865/ee89f33b-3e35-47af-a3fc-059417dad702) + +### 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 + +- **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 + +**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 + +### Team LinkedIn Profiles + +**Linkedin profiles** +- 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 Apache 2.0 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 Apache 2.0 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/JsonRpsee-socks5-proxy.md b/applications/JsonRpsee-socks5-proxy.md new file mode 100644 index 00000000000..223844b2069 --- /dev/null +++ b/applications/JsonRpsee-socks5-proxy.md @@ -0,0 +1,98 @@ +# 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 + +## 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. \ No newline at end of file diff --git a/applications/LiisaPortfolioTracker.md b/applications/LiisaPortfolioTracker.md index da742528247..297937c2695 100644 --- a/applications/LiisaPortfolioTracker.md +++ b/applications/LiisaPortfolioTracker.md @@ -5,7 +5,7 @@ - **[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 -PortoflioTrackerArchitectureNew +![Architecture New](https://github.com/LiisaNFT/W3F-Grants-Program/assets/139144686/5ded60b3-0409-44fb-a619-b47c0c6e7de7) ### 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..c3f23c1f3b4 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:** Ethereum: 0xA2db450Da91c1ab0bF3e247F0413541568bDdDaa (USDC) - **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/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/SpellRouter-proposal.md b/applications/SpellRouter-proposal.md new file mode 100644 index 00000000000..aa3d7b6ba72 --- /dev/null +++ b/applications/SpellRouter-proposal.md @@ -0,0 +1,302 @@ +# SpellRouter - XCM Router by ParaSpell✨ + +- **Team Name:** ParaSpell✨ +- **Payment Address:** bc1qa7m3f5cm5pcyh7m8f899kx59m93w496ld8nyux BTC +- **[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. + +![img1](https://user-images.githubusercontent.com/55763425/218987451-2bfc9526-8f2b-4477-8c42-8c70cbcb6ec4.jpg) + +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: + +![img2](https://user-images.githubusercontent.com/55763425/218987583-f5fb10b2-2e0c-4f36-b01c-0d610deab1c6.jpg) + +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. + +howapiworks + +### 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. +![1_59xApnboumYhzuRHKx60TA](https://user-images.githubusercontent.com/55763425/219314223-79c31085-2e90-4dc7-ad51-da96de730ea0.png) + +- Console printouts, SDK allows for printing into the console so developers can always check if the call they constructed is correct. +![1_2KT6Z1rxxprmE03XWYY-HA](https://user-images.githubusercontent.com/55763425/219314235-1da52511-b4e8-4a41-bdaa-04fa6a9e8a48.png) + +- 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. +docsgif + + +#### Architecture 🏗️ +##### Old +The old design had SDK integrated into dApp: + +![taskFlow](https://user-images.githubusercontent.com/55763425/198412240-e031d877-c5d8-4952-9048-2e1256ba4469.svg) + +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. + +![diag drawio](https://user-images.githubusercontent.com/55763425/275814797-d0472306-4e57-4bea-9d9b-86fac2afd125.svg) + +##### 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. + +![diadg drawio](https://user-images.githubusercontent.com/55763425/275827358-d0cf38cc-48e2-4b25-9853-8c2b59e0424f.svg) + +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: +![carbon](https://user-images.githubusercontent.com/55763425/275885095-14b21777-ed1f-494e-a524-6b2962271679.png) + +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: +![gfds drawio](https://user-images.githubusercontent.com/55763425/275976780-e1d47546-f75c-4788-81f0-388a2c71f183.svg) + + + +#### 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: +Screenshot 2023-10-16 at 21 42 53 + +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). +Screenshot 2023-10-16 at 18 50 37 + +## 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: + +certificate + +- 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/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/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..2c06687c5c1 100644 --- a/applications/application-template.md +++ b/applications/application-template.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.* @@ -117,7 +117,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 — Basic functionality @@ -163,7 +163,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/index.md b/applications/index.md index 2fcf4e1cc57..4bffdc9a1e4 100644 --- a/applications/index.md +++ b/applications/index.md @@ -51,6 +51,16 @@ Besides, **there is a clear difference between an application being accepted and | [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) | ☐ | ☐ | ☐ | [🔝](#top) @@ -61,16 +71,16 @@ Besides, **there is a clear difference between an application being accepted and | [Protofire](https://protofire.io/) | [Contract Wizard](./Contract_wizard.md) | [GitHub](https://github.com/protofire/polkadot-contract-wizard/) | ☐ | ☐ | ☐ | | [ZeroDAO](https://github.com/ZeroDAO) | [Melodot](./Melodot.md) | [GitHub](https://github.com/ZeroDAO) | ☐ | ☒ | ☒ | | [Starks](https://github.com/tur461) | [XCM tool for NFTs](./xNFT.md) | [GitHub](https://github.com/tur461) | ☐ | ☐ | ☐ | -| [ChainSafe](https://chainsafe.io/) | [Polkadot Snap Maintenance](./maintenance/Substratesnap_Maintenance.md) | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☐ | ☐ | +| [ChainSafe](https://chainsafe.io/) | [Polkadot Snap Maintenance](./maintenance/Substratesnap_Maintenance.md) | [GitHub](https://github.com/ChainSafe/metamask-snap-polkadot) | ☐ | ☒ | ☐ | | [justmert](https://github.com/justmert) | [DOTLY: Revolutionizing Polkadot Account Statistics](./dotly.md) | [GitHub](https://github.com/justmert/dotly) | ☐ | ☒ | ☒ | -| [Federico Cicciarella](https://www.linkedin.com/in/federicocicciarella/?originalSubdomain=it) | [Tracking Chain](./tracking_chain.md) | [GitHub](https://github.com/TrackingChains/TrackingChain) | ☐ | ☒ | ☐ | +| [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) | ☐ | ☒ | ☒ | | [MOBR Systems](https://www.mobr.ai) | [Polkadot Analytics Platform](polkadot_analytics_platform.md) | [GitHub](https://github.com/mobr-ai) | ☐ | ☒ | ☐ | @@ -80,17 +90,17 @@ Besides, **there is a clear difference between an application being accepted and | [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) | ☐ | ☐ | ☐ | | [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) | ☐ | ☐ | ☐ | +| [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) | ☐ | ☐ | ☐ | +| [Lastic](https://www.lastic.xyz/) | [Lastic](Lastic.md) | [GitHub](https://github.com/LasticXYZ) | ☐ | ☒ | ☒ | [🔝](#top) @@ -125,7 +135,7 @@ Besides, **there is a clear difference between an application being accepted and | [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) | ☐ | ☒ | ☐ | +| [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) | ☐ | ☒ | ☒ | @@ -162,7 +172,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) | ☐ | ☐ | ☐ | diff --git a/applications/lastic-price-simulation-2.md b/applications/lastic-price-simulation-2.md new file mode 100644 index 00000000000..4b188350c58 --- /dev/null +++ b/applications/lastic-price-simulation-2.md @@ -0,0 +1,155 @@ +# 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) + +### 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**: +- [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/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. + +![Image](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/polkagate/polkamask%20small.bmp) + + +### 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/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 +![dmp](https://github.com/MatteoPerona/riso-concept-files/blob/main/riso-frontend-ss01.png) +##### Home Page 2 +![dmp](https://github.com/MatteoPerona/riso-concept-files/blob/main/riso-frontend-ss02.png) +##### Home Page 3 +![dmp](https://github.com/MatteoPerona/riso-concept-files/blob/main/riso-frontend-ss03.png) +##### Marketplace +![dmp](https://github.com/MatteoPerona/riso-concept-files/blob/main/riso-frontend-ss04.png) +##### Purchase Contract +![dmp](https://github.com/MatteoPerona/riso-concept-files/blob/main/riso-frontend-ss05.png) +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/tux0.md b/applications/tux0.md new file mode 100644 index 00000000000..24c2c353f17 --- /dev/null +++ b/applications/tux0.md @@ -0,0 +1,225 @@ +# 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:** 12 weeks +- **Full-Time Equivalent (FTE):** 1,5 FTE +- **Total Costs:** 18,000 USD + +### Milestone 1 — Research 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 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. | +| 0e. | Article | 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. | +| 1. | Benchmarking program | We will develop a Rust program that will automatically run zk protocols benchmarks and export the results in a readable format, like JSON. | +| 2. | Protocols integration | We will provide an integration of at least 3 protocols for the benchmarking program, which will be used to produce the results. We will document the reasons for the choice of these protocols rather than other potential candidates. | +| 3. | 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. The core of this page will be embedded in the article as well. | + +### Milestone 2 — 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/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 ea5629fa7fb..0df98ec7e59 100644 --- a/docs/Introduction/intro.md +++ b/docs/Introduction/intro.md @@ -4,15 +4,16 @@ sidebar_position: 1 # Guidelines -Anyone is welcome to apply for a grant. Projects funded through our program are broad in scope, but our focus lies on projects with a strong **technical** focus that add value to the ecosystem. Furthermore, you should be able to demonstrate a solid, long-term roadmap, be it through the project's significance to the community (such as for research-oriented projects) or an in-depth market analysis (for business-oriented projects). +Anyone is welcome to apply for a grant. Projects funded through our program are broad in scope, but our focus lies on projects with a strong **technical** focus that add value to the Polkadot ecosystem. Furthermore, you should be able to demonstrate a solid, long-term roadmap, be it through the project's significance to the community (such as for research-oriented projects) or an in-depth market analysis (for business-oriented projects). Generally, your project will have better chances to be accepted if: - it presents a **well-researched** or tested concept, for which ideally you are able to show some prior work; +- you have tangible proof 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. +- 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: diff --git a/docs/Introduction/team.md b/docs/Introduction/team.md index a267b0379dd..cd279081ef2 100644 --- a/docs/Introduction/team.md +++ b/docs/Introduction/team.md @@ -6,7 +6,7 @@ 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. @@ -14,11 +14,9 @@ In cases where a niche expert opinion is desirable, one of the committee members - [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,10 +27,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 @@ -40,5 +36,4 @@ 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) diff --git a/docs/Process/how-to-apply.md b/docs/Process/how-to-apply.md index f6e95e10e96..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). ::: diff --git a/docs/RFPs/jsonrpsee-proxy-support.md b/docs/RFPs/jsonrpsee-proxy-support.md index 711c6633646..5f25149f087 100644 --- a/docs/RFPs/jsonrpsee-proxy-support.md +++ b/docs/RFPs/jsonrpsee-proxy-support.md @@ -1,6 +1,10 @@ # Socks5 proxy support for JsonRpsee -* **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://github.com/w3f/Grants-Program/blob/master/docs/RFPs/jsonrpsee-proxy-support.md) * **Proposer:** flipchan ## Project Description :page_facing_up: 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/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/funding.md b/docs/funding.md index 54a3977aa63..0624ba2928e 100644 --- a/docs/funding.md +++ b/docs/funding.md @@ -33,6 +33,7 @@ Below is a list of other grant and bounty programs in the Polkadot/Substrate eco - [Astar / Shiden Network Builders Program](https://github.com/PlasmNetwork/Builders-Program) - [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 62fc4f16dec..5237c46174e 100644 --- a/docs/rfps.md +++ b/docs/rfps.md @@ -26,7 +26,6 @@ If you find an open RFP here that you think you can address, feel free to [submi | [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 | -| [jsonrpsee-proxy-support.md](RFPs/jsonrpsee-proxy-support.md) | 19.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 | @@ -46,6 +45,7 @@ If you find an open RFP here that you think you can address, feel free to [submi | [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 | diff --git a/docusaurus.config.js b/docusaurus.config.js index 38256102c6b..726e753053c 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -28,7 +28,7 @@ module.exports = { announcementBar: { id: 'announcement', content: - 'Watch our sub0 presentation on Support in the Polkadot Ecosystem!', + 'Check out our newly created Decentralized Futures Program!', backgroundColor: '#000', textColor: '#ffffff', isCloseable: true,