diff --git a/.github/ISSUE_TEMPLATE/request-for-proposal.md b/.github/ISSUE_TEMPLATE/request-for-proposal.md new file mode 100644 index 00000000000..f9dc07bf271 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/request-for-proposal.md @@ -0,0 +1,47 @@ +--- +name: Request for Proposal +about: Suggest a project idea that should be funded by the Grants Program +title: "[RFP] " +labels: rfp +assignees: '' + +--- + +* **Status:** **Open** (anyone is allowed to apply) / **Closed** (invited respondents only) +* **Projects you think this work could be useful for** [optional]: Link(s) + +## Project Description + +Please describe exactly why you are proposing this RFP. Make sure to point out why it’s needed and/or useful for your project or other projects in the ecosystem. + +## Deliverables + +Please list potential deliverables of the project in as much detail as possible, but keep in mind that this roadmap is not binding and that applications might deviate from it. + +Please also estimate the amount of work required and try to divide the project into meaningful milestones. + +* **Total Estimated Duration:** Expected duration of the whole project +* **Full-time equivalent (FTE):** Expected number of full-time employees working on the project throughout its duration ([see](https://en.wikipedia.org/wiki/Full-time_equivalent)) +* **Total Costs:** Expected amount required, in USD, for the whole project. + +### Milestone 1 + +* **Estimated Duration:** Expected duration of Milestone 1 +* **FTE:** Expected number of full-time employees working on this milestone +* **Costs:** Expected amount required, in USD, for Milestone 1 + + +| Number | Deliverable | Specification | +| ----------- | --------------- | ----------------- | +| 1. | Title of the deliverable | Please describe the deliverable here as detailed as possible | +| 2. | ... | ... | + + +### Milestone 2 + +... + +--- + +* **Proposer:** Your GitHub username +* **Your Project(s):** [optional]: Link(s) diff --git a/.github/PULL_REQUEST_TEMPLATE/rfp_pr_template.md b/.github/PULL_REQUEST_TEMPLATE/rfp_pr_template.md index 76f7ad0c581..76834c8f723 100644 --- a/.github/PULL_REQUEST_TEMPLATE/rfp_pr_template.md +++ b/.github/PULL_REQUEST_TEMPLATE/rfp_pr_template.md @@ -14,5 +14,5 @@ ## Checklist -- [ ] I have checked the [open](https://github.com/w3f/General-Grants-Program/tree/master/rfps) and [implemented](https://github.com/w3f/General-Grants-Program/tree/master/rfps/implemented) RFPs to make sure this is not a duplicate. -- [ ] I have read and followed the [RFP Suggestion instructions](https://github.com/w3f/General-Grants-Program#mailbox_with_mail-request-for-proposals-rfp-suggestions). +- [ ] I have checked the [RFPs](https://github.com/w3f/Grants-Program/tree/master/docs/rfps) to make sure this is not a duplicate. +- [ ] I have read and followed the [RFP Suggestion instructions](https://github.com/w3f/Grants-Program#mailbox_with_mail-suggest-a-project). diff --git a/.github/labeler.yml b/.github/labeler.yml new file mode 100644 index 00000000000..06784d9379b --- /dev/null +++ b/.github/labeler.yml @@ -0,0 +1,13 @@ +"admin-review": +- changed-files: + - any-glob-to-any-file: applications/** + +"update docs": +- all: + - changed-files: + - any-glob-to-any-file: 'docs/**' + - all-globs-to-all-files: '!docs/RFPs/**' + +"rfp": +- changed-files: + - any-glob-to-any-file: docs/RFPs/** diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index bf6a53f40ba..13931e4a641 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -1,32 +1,3 @@ -### Project Abstract +The Web3 Foundation has decided to discontinue the Grants Program. Please do not submit any new applications. -> Please provide a brief description of your project here summarising key points (1-2 paragraphs). -> -> If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable. - -### For which grant [level](https://github.com/w3f/Grants-Program#level_slider-levels) are you applying? - -- [ ] **Level 1**: Up to $10,000, 2 approvals -- [ ] **Level 2**: Up to $30,000, 3 approvals -- [ ] **Level 3**: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval) - -### Application Checklist - -- [x] The [application template](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md) has been copied, renamed ( `project_name.md`) and updated. -- [ ] I have read and understood the [FAQs](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md), [application guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/grant_guidelines_per_category.md) and [announcement guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/announcement-guidelines.md). -- [ ] A BTC, Ethereum (USDT/USDC/DAI) or Polkadot/Kusama (aUSD) address for the payment of the milestones is provided inside the application. -- [ ] I have read and acknowledge the [terms and conditions](https://github.com/w3f/Grants-Program/blob/master/docs/T&Cs.md). -- [ ] 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). -- [ ] I prefer the discussion of this application to be in a private Element/Matrix channel. My username is: ``@_______`` - -### How Did You Hear About our grants program? - -- [ ] Social Media -- [ ] Hackathon -- [ ] Personal Recommendation -- [ ] Substrate Builders Program -- [ ] Investor/VC -- [ ] Online Search -- [ ] Other: _______ +For background, see https://medium.com/web3foundation/aligning-web3-foundation-grants-program-with-polkadots-product-centric-vision-9ae83baafdc3. diff --git a/.github/workflows/README.md b/.github/workflows/README.md index 7cb5356e913..57e7d7cbca6 100644 --- a/.github/workflows/README.md +++ b/.github/workflows/README.md @@ -2,12 +2,19 @@ ## Fork testing (on GitHub) + +0. Setup your Google API Credentials on https://console.developers.google.com/ + - Credentials -> Create Credentials -> Service Accounts + - Enable the Google Sheets API under [APIs and Services](https://console.cloud.google.com/apis/dashboard?project=festive-folio-343701) + 1. Fork the Open Grants repo (or create a private repo and push to it) 2. Set up your secrets under the fork/settings: - GSHEET_PRIVATE_KEY - GSHEET_CLIENT_EMAIL - SPREADSHEET_ID + - MATRIX_TOKEN + - MATRIX_CHANNEL_ID (for both matrix vars, refer to [this](https://github.com/fadenb/Matrix-Chat-Message) guide, W3F account is on 1Password) - ACTIONS_STEP_DEBUG: set this to true for more verbose logs on workflow runs - ACTIONS_RUNNER_DEBUG: similar as above, haven't tried it diff --git a/.github/workflows/application_accepted.yml b/.github/workflows/application_accepted.yml index 9c516a45013..2b957ef793e 100644 --- a/.github/workflows/application_accepted.yml +++ b/.github/workflows/application_accepted.yml @@ -19,7 +19,7 @@ jobs: - name: Get application filename # We assume there's only one if: ${{ !env.ACT }} id: 'files' - uses: Ana06/get-changed-files@v2.0.0 + uses: Ana06/get-changed-files@v2.3.0 with: filter: 'applications/*.md' format: 'csv' @@ -42,21 +42,21 @@ jobs: - name: Checkout if: ${{ !env.ACT }} - uses: actions/checkout@v2 + uses: actions/checkout@v4 - name: Parse application file if: ${{ !env.ACT }} id: grant_parser - uses: w3f/parse-grant-application-action@v1 + uses: w3f/parse-grant-application-action@v1.2 with: path: "${{ github.workspace }}/${{ needs.get_filename.outputs.filename }}" - name: Get current date id: date - run: echo "::set-output name=date::$(date +'%d/%m/%Y')" + run: echo "date=$(date +'%d/%m/%Y')" >> $GITHUB_OUTPUT - name: Add entry to Google Sheet - uses: jroehl/gsheet.action@v1.2.0 + uses: jroehl/gsheet.action@v2.1.1 with: spreadsheetId: ${{ secrets.SPREADSHEET_ID }} commands: | @@ -80,12 +80,13 @@ jobs: "https://github.com/w3f/Grants-Program/pull/${{ github.event.pull_request.number }}", "https://github.com/w3f/Grants-Program/pull/${{ github.event.pull_request.number }}", "USD", "0", "0", "0", - "${{ steps.grant_parser.outputs.total_cost_btc }}", + "", "${{ steps.grant_parser.outputs.total_cost_dai }}", + "${{ steps.grant_parser.outputs.dot_percentage }}", "", "", "Signed", - "https://github.com/w3f/Open-Grants-Program/pull/${{ github.event.pull_request.number }}", + "https://github.com/w3f/Grants-Program/pull/${{ github.event.pull_request.number }}", "${{ steps.date.outputs.date }}" ]], "worksheetTitle": "Legal", @@ -110,11 +111,11 @@ jobs: Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our [Milestone Delivery repository](https://github.com/w3f/Grant-Milestone-Delivery/) for instructions on how to submit milestones and invoices, our - [FAQ](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md) for frequently asked questions and the - [support section of our README](https://github.com/w3f/Grants-Program/blob/master/README.md#support) + [FAQ](https://grants.web3.foundation/docs/faq) for frequently asked questions and the + [support section on our website](https://grants.web3.foundation/docs/Introduction/support) for more ways to find answers to your questions.

Before you start, take a moment to read through our - [announcement guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/announcement-guidelines.md) + [announcement guidelines](https://grants.web3.foundation/docs/Support%20Docs/announcement-guidelines) for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at diff --git a/.github/workflows/check_application_document.yml b/.github/workflows/check_application_document.yml new file mode 100644 index 00000000000..44cad00dc40 --- /dev/null +++ b/.github/workflows/check_application_document.yml @@ -0,0 +1,37 @@ +name: Check application document + +on: + workflow_dispatch: + pull_request: + types: [opened, synchronize] + +jobs: + get_filename: + if: contains(github.event.pull_request.body, 'Project Abstract') + runs-on: ubuntu-latest + outputs: + filename: ${{ steps.files.outputs.added }} + steps: + + - name: Get application filename # We assume there's only one + id: 'files' + uses: Ana06/get-changed-files@v2.0.0 + with: + filter: 'applications/*.md' + format: 'csv' + + parse_document: + needs: get_filename + if: needs.get_filename.outputs.filename + runs-on: ubuntu-latest + permissions: + pull-requests: write + issues: write + steps: + - name: Checkout + uses: actions/checkout@v4 + - name: Parse application file + id: grant_parser + uses: w3f/parse-grant-application-action@master + with: + path: "${{ github.workspace }}/${{ needs.get_filename.outputs.filename }}" diff --git a/.github/workflows/check_broken_links.yml b/.github/workflows/check_broken_links.yml new file mode 100644 index 00000000000..7dda3b43d84 --- /dev/null +++ b/.github/workflows/check_broken_links.yml @@ -0,0 +1,29 @@ +name: Broken Links + +on: + repository_dispatch: + workflow_dispatch: + schedule: + - cron: '0 0 1 * *' # Trigger the workflow every month + +jobs: + build_and_check: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Link Checker + id: lychee + uses: lycheeverse/lychee-action@v1.8.0 + env: + GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} + with: + args: --verbose --no-progress !./applications/* + + - name: Create Issue From File + if: env.lychee_exit_code != 0 + uses: peter-evans/create-issue-from-file@v4 + with: + title: Link Checker Report + content-filepath: ./lychee/out.md + labels: report, automated issue diff --git a/.github/workflows/cla.yml b/.github/workflows/cla.yml new file mode 100644 index 00000000000..0110ffe390d --- /dev/null +++ b/.github/workflows/cla.yml @@ -0,0 +1,43 @@ +name: "CLA Assistant" +on: + issue_comment: + types: [created] + pull_request_target: + types: [opened,closed,synchronize] + +# explicitly configure permissions, in case your GITHUB_TOKEN workflow permissions are set to read-only in repository settings +permissions: + actions: write + contents: write + pull-requests: write + statuses: write + +jobs: + CLAAssistant: + runs-on: ubuntu-latest + steps: + - name: "CLA Assistant" + if: (github.event.comment.body == 'recheck' || github.event.comment.body == 'I have read and hereby sign the Contributor License Agreement.') || github.event_name == 'pull_request_target' + uses: contributor-assistant/github-action@v2.3.0 + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + # the below token should have repo scope and must be manually added by you in the repository's secret + # This token is required only if you have configured to store the signatures in a remote repository/organization + PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }} + with: + path-to-signatures: 'signatures/version1/cla.json' + path-to-document: 'https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/T%26Cs.md' + # branch should not be protected + branch: 'master' + allowlist: semuelle,takahser,Noc2,PieWol,keeganquigley,laboon,github-actions[bot] + + # the followings are the optional inputs - If the optional inputs are not given, then default values will be taken + remote-organization-name: w3f + remote-repository-name: grants-cla + #create-file-commit-message: 'For example: Creating file for storing CLA Signatures' + #signed-commit-message: 'For example: $contributorName has signed the CLA in $owner/$repo#$pullRequestNo' + custom-notsigned-prcomment: 'Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our [Contributor License Agreement](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/T%26Cs.md) before we can accept your contribution. Please submit the following text as a separate comment:' + custom-pr-sign-comment: 'I have read and hereby sign the Contributor License Agreement.' + #custom-allsigned-prcomment: 'pull request comment when all contributors has signed, defaults to **CLA Assistant Lite bot** All Contributors have signed the CLA.' + lock-pullrequest-aftermerge: false # if you don't want this bot to automatically lock the pull request after merging (default - true) + #use-dco-flag: true - If you are using DCO instead of CLA diff --git a/.github/workflows/codeql.yml b/.github/workflows/codeql.yml new file mode 100644 index 00000000000..f13423d4979 --- /dev/null +++ b/.github/workflows/codeql.yml @@ -0,0 +1,76 @@ +# For most projects, this workflow file will not need changing; you simply need +# to commit it to your repository. +# +# You may wish to alter this file to override the set of languages analyzed, +# or to provide custom queries or build logic. +# +# ******** NOTE ******** +# We have attempted to detect the languages in your repository. Please check +# the `language` matrix defined below to confirm you have the correct set of +# supported CodeQL languages. +# +name: "CodeQL" + +on: + push: + branches: [ "master" ] + pull_request: + # The branches below must be a subset of the branches above + branches: [ "master" ] + schedule: + - cron: '18 7 * * 5' + +jobs: + analyze: + name: Analyze + runs-on: ubuntu-latest + permissions: + actions: read + contents: read + security-events: write + + strategy: + fail-fast: false + matrix: + language: [ 'javascript' ] + # CodeQL supports [ 'cpp', 'csharp', 'go', 'java', 'javascript', 'python', 'ruby' ] + # Use only 'java' to analyze code written in Java, Kotlin or both + # Use only 'javascript' to analyze code written in JavaScript, TypeScript or both + # Learn more about CodeQL language support at https://aka.ms/codeql-docs/language-support + + steps: + - name: Checkout repository + uses: actions/checkout@v4 + + # Initializes the CodeQL tools for scanning. + - name: Initialize CodeQL + uses: github/codeql-action/init@v3 + with: + languages: ${{ matrix.language }} + # If you wish to specify custom queries, you can do so here or in a config file. + # By default, queries listed here will override any specified in a config file. + # Prefix the list here with "+" to use these queries and those in the config file. + + # Details on CodeQL's query packs refer to : https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#using-queries-in-ql-packs + # queries: security-extended,security-and-quality + + + # Autobuild attempts to build any compiled languages (C/C++, C#, Go, or Java). + # If this step fails, then you should remove it and run the build manually (see below) + - name: Autobuild + uses: github/codeql-action/autobuild@v3 + + # ℹ️ Command-line programs to run using the OS shell. + # 📚 See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun + + # If the Autobuild fails above, remove it and uncomment the following three lines. + # modify them (or add more) to build your code if your project, please refer to the EXAMPLE below for guidance. + + # - run: | + # echo "Run, Build Application using script" + # ./location_of_script_within_repo/buildscript.sh + + - name: Perform CodeQL Analysis + uses: github/codeql-action/analyze@v3 + with: + category: "/language:${{matrix.language}}" diff --git a/.github/workflows/enforce-label.yml b/.github/workflows/enforce-label.yml new file mode 100644 index 00000000000..77179753ae6 --- /dev/null +++ b/.github/workflows/enforce-label.yml @@ -0,0 +1,13 @@ +name: Enforce PR labels + +on: + pull_request: + types: [labeled, unlabeled, opened, edited, synchronize] +jobs: + enforce-label: + runs-on: ubuntu-latest + steps: + - uses: yogevbd/enforce-label-action@2.1.0 + with: + BANNED_LABELS: "admin-review" + BANNED_LABELS_DESCRIPTION: "Remove `admin-review` label for merge" diff --git a/.github/workflows/details_missing.yml b/.github/workflows/label_comment.yml similarity index 74% rename from .github/workflows/details_missing.yml rename to .github/workflows/label_comment.yml index 08916655cc6..c197f51a224 100644 --- a/.github/workflows/details_missing.yml +++ b/.github/workflows/label_comment.yml @@ -1,4 +1,4 @@ -name: ask_for_details +name: comment_on_label on: pull_request_target: @@ -21,7 +21,7 @@ jobs: [section on project details](https://github.com/w3f/Grants-Program/blob/master/applications/application-template.md#project-details) in the application template is a good reference as to what type of information we expect applicants to provide, and these - [category-specific requirements](https://github.com/w3f/Grants-Program/blob/master/docs/grant_guidelines_per_category.md) + [category-specific requirements](https://grants.web3.foundation/docs/Support%20Docs/grant_guidelines_per_category) contain more precise guidelines depending on what type of software you're building.
An area of the application that we often find to be insufficiently elaborated are the @@ -31,8 +31,19 @@ jobs: by other teams and in most cases not already present in the ecosystem. If they are, you will need to provide a comparison to existing implementations and explain why it makes sense to fund your approach. Also see our - [FAQ](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md#-general) + [FAQ](https://grants.web3.foundation/docs/faq#what-activitiespositions-do-you-fund) for a breakdown of what we fund and what we don't.
Let us know as soon as you're done with your changes, and we'll give your application another look! GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + + private_conversation: + if: github.event.label.name == 'discussion private' + runs-on: ubuntu-latest + steps: + - name: Comment PR + uses: thollander/actions-comment-pull-request@1.0.2 + with: + message: > + The applicant has requested the discussion of the application to happen in a private chat room. + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/labeler.yml b/.github/workflows/labeler.yml new file mode 100644 index 00000000000..511291def7d --- /dev/null +++ b/.github/workflows/labeler.yml @@ -0,0 +1,14 @@ +name: "Pull Request Labeler" +on: +- pull_request_target + +jobs: + labeler: + permissions: + contents: read + pull-requests: write + runs-on: ubuntu-latest + steps: + - uses: actions/labeler@v5 + with: + github_token: ${{ secrets.GITHUB_TOKEN }} diff --git a/.github/workflows/private-labeler.yml b/.github/workflows/private-labeler.yml new file mode 100644 index 00000000000..096debb3496 --- /dev/null +++ b/.github/workflows/private-labeler.yml @@ -0,0 +1,30 @@ +name: Check for private discussion + +on: + workflow_dispatch: + pull_request: + types: [opened, edited] + +jobs: + discussion_private: + if: | + contains(github.event.pull_request.body, 'Project Abstract') && ( + !contains(github.event.pull_request.body, '- [ ] I prefer the discussion') || + ( + contains(github.event.pull_request.body, '- [ ] I prefer the discussion') && + !contains(github.event.pull_request.body, '@_______:matrix.org') + ) + ) + runs-on: ubuntu-latest + steps: + - name: Add 'discussion private' label if the application is private + uses: actions/github-script@v6 + with: + github-token: ${{ secrets.GITHUB_TOKEN }} + script: | + github.rest.issues.addLabels({ + issue_number: context.issue.number, + owner: context.repo.owner, + repo: context.repo.repo, + labels: ["discussion private"] + }) diff --git a/.github/workflows/publish.yml b/.github/workflows/publish.yml new file mode 100644 index 00000000000..a10bb577e59 --- /dev/null +++ b/.github/workflows/publish.yml @@ -0,0 +1,34 @@ +name: Publish website + +on: + push: + branches: + - master + +jobs: + build: + if: github.repository_owner == 'w3f' + name: build and deploy + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + - uses: actions/setup-node@v4 + with: + node-version: '22' + - uses: actions/checkout@v4 + with: + fetch-depth: 0 + - name: Publish + run: | + git config --global user.email "grants-deployer@users.noreply.github.com" + git config --global user.name "grants-deployer" + echo "machine github.com login grants-deployer password ${{ secrets.ACCESS_KEY }}" > ~/.netrc + yarn && yarn build && GIT_USER=grants-deployer PUBLISHING=true yarn deploy + - if: ${{ failure() }} + uses: fadenb/matrix-chat-message@v0.0.6 + with: + homeserver: 'matrix.web3.foundation' + token: ${{ secrets.MATRIX_TOKEN }} + channel: ${{ secrets.MATRIX_CHANNEL_ID }} + message: | + WEBSITE BUILD FAILED: [This](https://github.com/w3f/Grants-Program/commit/${{ github.sha }}) is the last push commit. diff --git a/.github/workflows/ready_for_review.yml b/.github/workflows/ready_for_review.yml new file mode 100644 index 00000000000..980fc308d49 --- /dev/null +++ b/.github/workflows/ready_for_review.yml @@ -0,0 +1,17 @@ +name: Ready for Review notification + +on: + pull_request_target: + types: [ready_for_review] + +jobs: + send_matrix_review_msg: + runs-on: ubuntu-latest + steps: + - uses: fadenb/matrix-chat-message@v0.0.6 + with: + homeserver: 'matrix.web3.foundation' + token: ${{ secrets.MATRIX_TOKEN }} + channel: ${{ secrets.MATRIX_CHANNEL_ID }} + message: | + PR READY FOR REVIEW: [${{ github.event.pull_request.title }}](https://github.com/w3f/Grants-Program/pull/${{ github.event.pull_request.number }}) is ready for review. Labeled by ${{ github.event.sender.login }}; \ No newline at end of file diff --git a/.github/workflows/stale_checker.yml b/.github/workflows/stale_checker.yml new file mode 100644 index 00000000000..83c4ae98908 --- /dev/null +++ b/.github/workflows/stale_checker.yml @@ -0,0 +1,25 @@ +name: Stale checker + +on: + schedule: + - cron: '0 7 * * *' # run at 7:00 UTC every day + workflow_dispatch: + +jobs: + mark_as_stale: + if: github.repository_owner == 'w3f' + runs-on: ubuntu-latest + steps: + - id: stale + uses: w3f/label-stale-pull-requests@main + with: + context: ${{ toJSON(github) }} + token: ${{ secrets.GITHUB_TOKEN }} + - if: steps.stale.outputs.message != '' + uses: fadenb/matrix-chat-message@v0.0.6 + with: + homeserver: 'matrix.web3.foundation' + token: ${{ secrets.MATRIX_TOKEN }} + channel: ${{ secrets.MATRIX_CHANNEL_ID }} + message: | + ${{ steps.stale.outputs.message }} diff --git a/.github/workflows/status_badges.yml b/.github/workflows/status_badges.yml deleted file mode 100644 index 63cc12fa39a..00000000000 --- a/.github/workflows/status_badges.yml +++ /dev/null @@ -1,20 +0,0 @@ -name: Update Status Badges -on: - schedule: - - cron: '0 0 * * *' - workflow_dispatch: - -jobs: - status_badges: - runs-on: ubuntu-latest - name: Update status badges - steps: - - name: Checkout - uses: actions/checkout@v3 - - name: Check and update badges - uses: w3f/status-badges@v1.1 - with: - path: 'docs/polkadot_stack.md' - token: ${{ secrets.GITHUB_TOKEN }} - find-all-links: true - pull-request: true diff --git a/.gitignore b/.gitignore index c706597d5c7..e87606b1bdd 100644 --- a/.gitignore +++ b/.gitignore @@ -61,3 +61,8 @@ $RECYCLE.BIN/ # IDE settings .vscode +node_modules + +# docusaurus +build/ +.docusaurus/ diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index fc914097d0d..2f27862ac1a 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -2,75 +2,127 @@ ## Our Pledge -In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, sex characteristics, gender identity and expression, -level of experience, education, socio-economic status, nationality, personal -appearance, race, religion, or sexual identity and orientation. +We as members, contributors, and leaders pledge to make participation in our +community a harassment-free experience for everyone, regardless of age, body +size, visible or invisible disability, ethnicity, sex characteristics, gender +identity and expression, level of experience, education, socio-economic status, +nationality, personal appearance, race, religion, or sexual identity +and orientation. + +We pledge to act and interact in ways that contribute to an open, welcoming, +diverse, inclusive, and healthy community. ## Our Standards -Examples of behavior that contributes to creating a positive environment -include: +Examples of behavior that contributes to a positive environment for our +community include: -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members +* Demonstrating empathy and kindness toward other people +* Being respectful of differing opinions, viewpoints, and experiences +* Giving and gracefully accepting constructive feedback +* Accepting responsibility and apologizing to those affected by our mistakes, + and learning from the experience +* Focusing on what is best not just for us as individuals, but for the + overall community -Examples of unacceptable behavior by participants include: +Examples of unacceptable behavior include: -* The use of sexualized language or imagery and unwelcome sexual attention or - advances -* Trolling, insulting/derogatory comments, and personal or political attacks +* The use of sexualized language or imagery, and sexual attention or + advances of any kind +* Trolling, insulting or derogatory comments, and personal or political attacks * Public or private harassment -* Publishing others' private information, such as a physical or electronic - address, without explicit permission +* Publishing others' private information, such as a physical or email + address, without their explicit permission * Other conduct which could reasonably be considered inappropriate in a - professional setting + professional setting -## Our Responsibilities +## Enforcement Responsibilities -Project maintainers are responsible for clarifying the standards of acceptable -behavior and are expected to take appropriate and fair corrective action in -response to any instances of unacceptable behavior. +Community leaders are responsible for clarifying and enforcing our standards of +acceptable behavior and will take appropriate and fair corrective action in +response to any behavior that they deem inappropriate, threatening, offensive, +or harmful. -Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful. +Community leaders have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, and will communicate reasons for moderation +decisions when appropriate. ## Scope -This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers. +This Code of Conduct applies within all community spaces, and also applies when +an individual is officially representing the community in public spaces. +Examples of representing our community include using an official e-mail address, +posting via an official social media account, or acting as an appointed +representative at an online or offline event. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at grants@web3.foundation. All -complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. +reported to the community leaders responsible for enforcement at +grants@web3.foundation. +All complaints will be reviewed and investigated promptly and fairly. + +All community leaders are obligated to respect the privacy and security of the +reporter of any incident. + +## Enforcement Guidelines + +Community leaders will follow these Community Impact Guidelines in determining +the consequences for any action they deem in violation of this Code of Conduct: + +### 1. Correction + +**Community Impact**: Use of inappropriate language or other behavior deemed +unprofessional or unwelcome in the community. + +**Consequence**: A private, written warning from community leaders, providing +clarity around the nature of the violation and an explanation of why the +behavior was inappropriate. A public apology may be requested. + +### 2. Warning -Project maintainers who do not follow or enforce the Code of Conduct in good -faith may face temporary or permanent repercussions as determined by other -members of the project's leadership. +**Community Impact**: A violation through a single incident or series +of actions. + +**Consequence**: A warning with consequences for continued behavior. No +interaction with the people involved, including unsolicited interaction with +those enforcing the Code of Conduct, for a specified period of time. This +includes avoiding interactions in community spaces as well as external channels +like social media. Violating these terms may lead to a temporary or +permanent ban. + +### 3. Temporary Ban + +**Community Impact**: A serious violation of community standards, including +sustained inappropriate behavior. + +**Consequence**: A temporary ban from any sort of interaction or public +communication with the community for a specified period of time. No public or +private interaction with the people involved, including unsolicited interaction +with those enforcing the Code of Conduct, is allowed during this period. +Violating these terms may lead to a permanent ban. + +### 4. Permanent Ban + +**Community Impact**: Demonstrating a pattern of violation of community +standards, including sustained inappropriate behavior, harassment of an +individual, or aggression toward or disparagement of classes of individuals. + +**Consequence**: A permanent ban from any sort of public interaction within +the community. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, -available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 2.0, available at +https://www.contributor-covenant.org/version/2/0/code_of_conduct.html. + +Community Impact Guidelines were inspired by [Mozilla's code of conduct +enforcement ladder](https://github.com/mozilla/diversity). [homepage]: https://www.contributor-covenant.org -For answers to common questions about this code of conduct, see -https://www.contributor-covenant.org/faq +For answers to common questions about this code of conduct, see the FAQ at +https://www.contributor-covenant.org/faq. Translations are available at +https://www.contributor-covenant.org/translations. diff --git a/README.md b/README.md index d04f6a8638b..1b329abc648 100644 --- a/README.md +++ b/README.md @@ -1,34 +1,39 @@ +> [!IMPORTANT] +> **The Web3 Foundation has decided to [discontinue the general Grants Program](https://medium.com/web3foundation/aligning-web3-foundation-grants-program-with-polkadots-product-centric-vision-9ae83baafdc3).** We are not accepting new applications at this point. Please do not submit new pull requests. + # Web3 Foundation Grants Program

- +

- [:wave: Introduction](#wave-introduction) - [Guidelines](#guidelines) - - [Project ideas](#project-ideas) + - [Project Ideas](#project-ideas) - [Support](#support) - [Team](#team) -- [:level_slider: Levels](#level_slider-levels) +- [:level\_slider: Levels](#level_slider-levels) - [:pencil: Process](#pencil-process) - [1. Application](#1-application) - [2. Application Review](#2-application-review) - [3. Milestone Delivery and Payment](#3-milestone-delivery-and-payment) - [Changes to a Grant after Approval](#changes-to-a-grant-after-approval) -- [:mailbox_with_mail: Suggest a Project](#mailbox_with_mail-suggest-a-project) -- [:hammer_and_wrench: Maintenance Grants](#hammer_and_wrench-maintenance-grants) +- [:mailbox\_with\_mail: Suggest a Project](#mailbox_with_mail-suggest-a-project) +- [:hammer\_and\_wrench: Maintenance Grants](#hammer_and_wrench-maintenance-grants) +- [:moneybag: Referral Program](#moneybag-referral-program) - [:bulb: Help](#bulb-help) - - [Additional information](#additional-information) - - [Real-time conversation](#real-time-conversation) + - [Real-time Conversation](#real-time-conversation) + - [Ecosystem Funding Office Hours](#ecosystem-funding-office-hours) - [:rocket: Alternative Funding Sources](#rocket-alternative-funding-sources) + - [Treasury vs Web3 Grants](#treasury-vs-web3-grants) - [Treasury](#treasury) - [Hackathons](#hackathons) - - [Other Grant Programs](#other-grant-programs) + - [Other Grant or Bounty Programs](#other-grant-or-bounty-programs) ## :wave: Introduction -As part of our commitment to promoting the Web3 ecosystem, we offer a comprehensive grants program focused on funding software development and research efforts related to **Polkadot, Kusama, [Substrate](https://github.com/paritytech/substrate) and [ink!](https://github.com/paritytech/ink)**. For more information about the Web3 Foundation, please visit the [About page](https://web3.foundation/about/) on our website. +As part of our commitment to promoting the Web3 ecosystem, we offer a comprehensive grants program focused on funding software development and research efforts related to **Polkadot and Kusama**. For more information about the Web3 Foundation, please visit the [About page](https://web3.foundation/about/) on our website. ### Guidelines @@ -36,40 +41,109 @@ Anyone is welcome to apply for a grant. Projects funded through our programs are Generally, your project will have better chances to be accepted if: -- It presents a **well-researched** or tested concept, for which ideally you are able to show some prior work. -- You can demonstrate that the project will be **maintained** after completion of the grant, be it through an obvious commitment to the technology from your side, additional funding sources or an existing business model. -- Your team has **proven experience** with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine these for past activity and code quality. Naturally, you can also link to projects on other platforms. +- It presents a **well-researched** or tested concept, for which, ideally, you are able to show some prior work. +- You can demonstrate that the project will be **maintained** after completion of the grant, be it through an obvious commitment to the technology from your side, additional funding sources, or an existing business model. +- Your team has **proven experience** with the relevant languages and technologies and/or a strong technical background. You will be asked to provide the GitHub profiles of your team members as part of your application, which we will examine for past activity and code quality. Naturally, you can also link to projects on other platforms. - Your application is **rich in technical details** and well-defined. - You can clearly present how your project stands out among competitors or implements technology that doesn't exist in the ecosystem yet. Additionally, it must fulfill the following requirements: -- All code produced as part of a grant must be **open-sourced**, and it must also not rely on closed-source software for full functionality. We prefer Apache 2.0, but GPLv3, MIT or Unlicense are also acceptable. +- All code produced as part of a grant must be **open-sourced**, and it must also not rely on closed-source software for full functionality. We prefer Apache 2.0, but GPLv3, MIT, or Unlicense are also acceptable. - We do not award grants for projects that have been the object of a successful token sale. +- Applications must not mention a specific token. Furthermore, the focus of the application should lie on the software that is being implemented/research being carried out as part of the grant and less on your project/venture/operation. For the purpose of the application and delivery, think about how others might also benefit from your work. - As a general rule, teams are asked to finish a grant before applying for another one. -- Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering or criminal activities in general. +- Lastly, we do not fund projects that actively encourage gambling, illicit trade, money laundering, or criminal activities in general. -In addition to the information provided on your application, note that your project will need to comply with our [Guidelines for Milestone Deliverables](docs/milestone-deliverables-guidelines.md). In particular, we require all projects to create documentation that explains how their project works. At a minimum, _written_ documentation is required for funding. Tutorials or videos are also helpful for new users to understand how to use your product. +In addition to the information provided on your application, note that your project will need to comply with our [Guidelines for Milestone Deliverables](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/milestone-deliverables-guidelines.md). In particular, we require all projects to create documentation that explains how their project works. At a minimum, _written_ documentation is required for funding. Tutorials or videos are also helpful for new users to understand how to use your product. -Please also heed our [Announcement Guidelines](docs/announcement-guidelines.md) for grant-related communications. +Please also heed our [Announcement Guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/announcement-guidelines.md) for grant-related communications. Finally, we take licensing and the right of all teams in and outside the ecosystem to be recognised for their work very seriously. Using others' work with no attribution or indication that this was not your own work as part of a milestone delivery **will lead to immediate termination**. Please reach out to us before submitting if you have any doubts on how to comply with a specific license and we'll be happy to help. -We also try to enforce our [code of conduct](CODE_OF_CONDUCT.md) and based on this may [block users](https://github.blog/2016-04-04-organizations-can-now-block-abusive-users/). +We also try to enforce our [code of conduct](CODE_OF_CONDUCT.md) and, based on this, may [block users](https://github.blog/2016-04-04-organizations-can-now-block-abusive-users/). + +### What We're Looking For + +We're excited to support projects that align with our vision for a thriving Web3 ecosystem. Here's what makes us particularly enthusiastic about an application: + +**💡 User-Centric Innovation** +- Projects that focus on real user needs and can serve a broad user base +- Solutions that address practical challenges and improve user experiences + +**🔄 Dogfooding & Practical Value** +- Projects that can be actively used and tested by Web3 Foundation, Parity, your team, and the broader ecosystem +- Tools and applications that solve problems we face ourselves + +**🪙 DOT Token Alignment** +- Projects that create tangible demand and usage for the DOT token +- Solutions that strengthen the Polkadot ecosystem's economic foundation + +**💰 Sustainable Business Models** +- Teams demonstrating strong financial discipline and clear planning +- Projects with a realistic path to financial independence within 12-24 months +- Evidence of thoughtful resource management and business strategy + +**⚖️ Regulatory Awareness** +- Projects that understand and comply with regulatory requirements in their target markets +- Teams that proactively consider compliance and legal considerations + +**🌟 Exciting Verticals** + +We're particularly interested in (but not limited to) these areas: +- **Cross-border payments & stablecoins**, especially serving Latin America and Southeast Asia +- **AI applications** like content authentication and verification systems +- **DePIN/IoT solutions** with concrete, marketable products +- **Proof-of-personhood** implementations and identity solutions +- **Web2 to Web3 bridges** - bringing familiar concepts (think HackMD, Spotify-like experiences) to Polkadot + +### What Doesn't Fit Our Program + +To help you determine if our program is the right fit, here are types of projects we typically don't fund: + +**❌ Generic Approaches** +- Projects based on generic talking points from other ecosystems without Polkadot-specific innovation +- Applications that could apply to any blockchain without meaningful differentiation + +**🪙 Token-Only Focus** +- Projects focused primarily on token sales rather than providing genuine utility +- Applications where the main value proposition is speculative trading + +**📈 Marketing Without Substance** +- Pure marketing efforts without concrete technical deliverables +- Projects aimed at "saving" or promoting other projects through marketing alone +- Generic promotional activities without defined use cases + +**💸 Financial Sustainability Concerns** +- Teams without clear financial planning or path to sustainability +- Projects that don't demonstrate responsible resource management +- Applications lacking realistic business models or revenue streams -### Project ideas +**🔒 Limited Usability** +- Products that we and the community cannot meaningfully test or use +- Solutions that exist in isolation without practical application -An overview of existing projects in the Web 3.0 Technology Stack along with broad project ideas we would potentially be interested in funding can be found [here](docs/polkadot_stack.md), as well as a list of previously accepted applications [here](docs/accepted_grant_applications.md). +**🌐 Misaligned Objectives** +- Projects that don't create meaningful demand or usage for DOT tokens +- Solutions that could easily exist on any blockchain without leveraging Polkadot's unique features -[Requests For Proposals](rfps) (RFPs) represent concrete ideas for projects that we would like to see implemented. Several teams may apply for the same RFP, so even if another team has already applied to implement a certain RFP, we invite you to do the same if you're interested. +**⚖️ Regulatory Blindness** +- Projects that ignore or are unaware of regulatory requirements in their target markets +- Teams that haven't considered compliance implications for their solutions + +### Project Ideas + +An overview of existing projects in the Web 3.0 Technology Stack, along with broad project ideas we would potentially be interested in funding, can be found [here](https://wiki.polkadot.network/docs/build-open-source), as well as a list of previously accepted applications [here](https://github.com/w3f/Grants-Program/blob/master/applications/index.md). + +[Requests For Proposals](https://github.com/w3f/Grants-Program/blob/master/docs/rfps.md) (RFPs) represent concrete ideas for projects that we would like to see implemented. Several teams may apply for the same RFP, so even if another team has already applied to implement a certain RFP, we invite you to do the same if you're interested. Finally, you don't need to start your own project in order to be eligible for a grant. Instead, some teams choose to port existing work to Substrate, where the pertinent licenses allow, or even to contribute to an existing open-source project. In the latter case, you should check in advance that the maintainers of the project are interested in your contribution, and the acceptance of the milestones will generally be tied to the inclusion of your work in said project. See the [Maintenance Grants section](#hammer_and_wrench-maintenance-grants) for more info. -If you have a **good concept of the technical challenges** that your idea entails and would like feedback before applying, you can send us an [email](mailto:grants@web3.foundation) and tell us about it. +If you have a **good concept of the technical challenges** that your idea entails and would like feedback/input before submitting it, you can send us an [email](mailto:grants@web3.foundation) and tell us about it. ### Support -The scope of our Grants Programs consists of funding and feedback on delivered milestones. This means that we do not provide hands-on support as part of a grant, but if you face specific issues during development, we will do our best and try to direct you to the correct resources. If this sounds like something you would like however, you may also want to apply to Parity's [Substrate Builders Program](https://www.substrate.io/builders-program/), which provides hands-on technical, ecosystem and strategical long-term support and access to extensive resources. You can find general documentation and more information on Substrate on the [Substrate Developer Hub](https://substrate.dev/), and we encourage you to join the [community](https://substrate.dev/en/community) in order to get help with specific issues or to stay up to date with the most recent developments. +The scope of our Grants Programs consists of funding and feedback on delivered milestones. This means that we do not provide hands-on support as part of a grant, but if you face specific issues during development, we will do our best and try to direct you to the correct resources. You can find general documentation and more information on Substrate on the [Substrate Developer Hub](https://substrate.dev/), and we encourage you to join the [community](https://substrate.dev/en/community) in order to get help with specific issues or to stay up to date with the most recent developments. For questions about the grants program itself, see our [FAQ](docs/faq.md#frequently-asked-questions). @@ -77,49 +151,43 @@ For questions about the grants program itself, see our [FAQ](docs/faq.md#frequen #### W3F Grants Committee -The committee consists of individuals who know the funding priorities of the Polkadot ecosystem, and is responsible for evaluating grant applications and providing feedback on these. +The committee consists of individuals who know the funding priorities of the Polkadot ecosystem and is responsible for evaluating grant applications and providing feedback on these. In cases where a niche expert opinion is desirable, one of the committee members may request such a review. - [Santiago Balaguer](https://github.com/SBalaguer) - [Aeron Buchanan](https://github.com/aeronbuchanan) -- [Gautam Dhameja](https://github.com/gautamdhameja) -- [Ashley Grevelink](https://github.com/cruikshankss) -- [David Hawig](https://github.com/Noc2) +- [Radhakrishna Dasari](https://github.com/DrW3RK) - [Sebastian Müller](https://github.com/semuelle) - [Bill Laboon](https://github.com/laboon) -- [Raul Romanutti](https://github.com/rrtti) -- [Aleixo Sánchez](https://github.com/alxs) -- [Seraya Takahashi](https://github.com/takahser) -- [Reto Trinkler](https://github.com/retotrinkler) -- [Benjamin Weiß](https://github.com/BenWhiteJam) +- [Keegan Quigley](https://github.com/keeganquigley) +- [Piet Wolff](https://github.com/PieWol) - [Gavin Wood](https://github.com/gavofyork) +- [Aleksandar Dimitrijevic](https://github.com/alexdimes) +- [Diogo Silveira Mendonca](https://github.com/diogo-w3f) #### W3F Grants Evaluators 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. -- [Ashley Grevelink](https://github.com/cruikshankss) -- [David Hawig](https://github.com/Noc2) - [Sebastian Müller](https://github.com/semuelle) -- [Aleixo Sánchez](https://github.com/alxs) -- [Seraya Takahashi](https://github.com/takahser) +- [Keegan Quigley](https://github.com/keeganquigley) +- [Piet Wolff](https://github.com/PieWol) +- [Diogo Silveira Mendonca](https://github.com/diogo-w3f) #### W3F Operations Team -The Operations Team takes care of legal documents, invoicing and remittances. +The Operations Team takes care of legal documents, invoicing, and remittances. - [Melanie Diener](https://github.com/meldien) -- [Federica Dubbini](https://github.com/fededubbi) -- [Kasper Mai Jørgensen](https://github.com/KasperJor) - [Rouven Pérez](https://github.com/RouvenP) ## :level_slider: Levels -The W3F Grants Program offers different grant levels to help you best depending on your current stage. +The W3F Grants Program offers different grant levels to help you best, depending on your current stage. At least 50% of any grant is paid out in vested DOT. -### :hatching_chick: Level 1 (= InstaGrants) +### :hatching_chick: Level 1 - **Target:** Individuals & small teams - **Amount:** Up to $10,000 @@ -131,7 +199,7 @@ The W3F Grants Program offers different grant levels to help you best depending - **Target:** Small teams/start-ups - **Amount:** Up to $30,000 - **Requirements:** 3 approvals -- **Benefits:** All of the above + [co-promotion](./docs/announcement-guidelines.md#announcement-guidelines), [Grants Program badge](./docs/grant-badge-guidelines.md), fast track to [Substrate Builders Program](https://www.substrate.io/builders-program/) +- **Benefits:** All of the above + [co-promotion](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/announcement-guidelines.md), [Grants Program badge](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/grant-badge-guidelines.md) ### :rooster: Level 3 @@ -142,25 +210,25 @@ The W3F Grants Program offers different grant levels to help you best depending ## :pencil: Process -> **:loudspeaker:** The process below is independent of the [level](#level_slider-levels). Payment is made in Bitcoin, USDT, USDC, DAI or aUSD. If you want to apply in **private** and/or you need to be paid out in **fiat**, you can apply [: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:** At least 50% (as defined in your grant agreement) of each milestone payment is made in DOT (linearly vesting over 2 years). The remainder is paid in USDC on the Polkadot [AssetHub](https://wiki.polkadot.network/docs/learn-assets). 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** or your project does not fit this program for any reason, you can reach out to us [:arrow_right: here](https://grants.web3.foundation/docs/office-hours). ### 1. Application - 0. Please read our [FAQs](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md), [category guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/grant_guidelines_per_category.md), [announcement guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/announcement-guidelines.md) and [Terms & Conditions](https://github.com/w3f/Grants-Program/blob/master/docs/T%26Cs.md) to familiarize yourself with the subtleties of grants, applications and the program as a whole. + 0. Please read our [FAQs](https://github.com/w3f/Grants-Program/blob/master/docs/faq.md), [category guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/grant_guidelines_per_category.md), [announcement guidelines](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/announcement-guidelines.md) and [Terms & Conditions](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/T%26Cs.md) to familiarize yourself with the subtleties of grants, applications and the program as a whole. 1. [Fork](https://github.com/w3f/Grants-Program/fork) this repository. - 2. In the newly created fork, create a copy of the application template ([`applications/application-template.md`](applications/application-template.md)). If you're using the GitHub web interface, you will need to create a new file and copy the [contents](https://raw.githubusercontent.com/w3f/Grants-Program/master/applications/application-template.md) of the template inside the new one. Make sure you **do not modify the template file directly**. In the case of a maintenance application, use the maintenance template ([`maintenance template`](maintenance/maintenance-template.md)) instead. + 2. In the newly created fork, create a copy of the application template ([`applications/application-template.md`](applications/application-template.md)). If you're using the GitHub web interface, you will need to create a new file and copy the [contents](https://raw.githubusercontent.com/w3f/Grants-Program/master/applications/application-template.md) of the template inside the new one. Make sure you **do not modify the template file directly**. In the case of a maintenance application, use the maintenance template ([`maintenance template`](applications/maintenance/maintenance-template.md)) instead. In the case of a research application, use the research template ([`research template`](applications/application-template-research.md)) instead. 3. Name the new file after your project: `project_name.md`. - 4. Fill out the template with the details of your project. The more information you provide, the faster the review. Please refer to our [Grant guidelines for most popular grant categories](docs/grant_guidelines_per_category.md) and make sure your deliverables present a similar same level of detail. To get an idea of what a strong application looks like, you can have a look at the following examples: [1](https://github.com/w3f/Grants-Program/blob/master/applications/project_aurras_mvp_phase_1.md), [2](https://github.com/w3f/Grants-Program/blob/master/applications/project_bodhi.md), [3](https://github.com/w3f/Grants-Program/blob/master/applications/pontem.md), [4](https://github.com/w3f/Grants-Program/blob/master/applications/spartan_poc_consensus_module.md). Naturally, if you're only applying for a smaller grant that only consists of, say, UI work, you don't need to provide as much detail. - 5. Once you're done, create a pull request. The pull request should only contain _one new file_—the Markdown file you created from the template. + 4. Fill out the template with the details of your project. The more information you provide, the faster the review. Please refer to our [Grant guidelines for most popular grant categories](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/grant_guidelines_per_category.md) and make sure your deliverables present a similar same level of detail. To get an idea of what a strong application looks like, you can have a look at the following examples: [1](https://github.com/w3f/Grants-Program/blob/master/applications/project_aurras_mvp_phase_1.md), [2](https://github.com/w3f/Grants-Program/blob/master/applications/project_bodhi.md), [3](https://github.com/w3f/Grants-Program/blob/master/applications/pontem.md), [4](https://github.com/w3f/Grants-Program/blob/master/applications/spartan_poc_consensus_module.md). Naturally, if you're only applying for a smaller grant that only consists of, say, UI work, you don't need to provide as much detail. + 5. Once you're done, create a pull request in **our** main [Grants-Program repository](https://github.com/w3f/Grants-Program). The pull request should only contain _one new file_—the Markdown file you created from the template. 6. You will see a comment template that contains a checklist. You can leave it as is and tick the checkboxes once the pull request has been created. Please read through these items and check all of them. - 7. Sign off on the [terms and conditions](docs/T&Cs.md) presented by the [CLA assistant](https://github.com/claassistantio) bot as a Contributor License Agreement. You might need to reload the pull request to see its comment. + 7. Sign off on the [terms and conditions](https://github.com/w3f/Grants-Program/blob/master/docs/Support%20Docs/T%26Cs.md) presented by the [CLA assistant](https://github.com/claassistantio) bot as a Contributor License Agreement. You might need to reload the pull request to see its comment. ### 2. Application Review 1. The [committee](#w3f-grants-committee) can (and usually does) issue comments and request changes on the pull request. 2. Clarifications and amendments made in the comments _need to be included in the application_. You may address feedback by directly modifying your application and leaving a comment once you're done. Generally, if you don't reply within 2 weeks, the application will be closed due to inactivity, but you're always free to reopen it as long as it hasn't been rejected. - 3. When all requested changes are addressed and the terms and conditions have been signed, someone will mark your application as `ready for review` and share it internally with the rest of the committee. - 4. The application will be accepted and merged as soon as it receives the required number of approvals (see [levels](#level_slider-levels)), or closed after two weeks of inactivity. Unless specified otherwise, the day on which it is accepted will be considered the starting date of the project, and will be used to estimate delivery dates. + 3. When all requested changes are addressed, and the terms and conditions have been signed, someone will mark your application as `ready for review` and share it internally with the rest of the committee. + 4. The application will be accepted and merged as soon as it receives the required number of approvals (see [levels](#level_slider-levels)) or closed after two weeks of inactivity. Unless specified otherwise, the day on which it is accepted will be considered the starting date of the project, and will be used to estimate delivery dates. ### 3. Milestone Delivery and Payment @@ -170,26 +238,33 @@ The W3F Grants Program offers different grant levels to help you best depending - Accepted grant applications can be amended at any time. However, this _necessitates a reevaluation by the committee_ and the same number of approvals as an application (according to the [levels](#level_slider-levels)). If your application has been accepted and, during development, you find that your project significantly deviates from the original specification, please open a new pull request that modifies the existing application. This also applies in case of significant delays. - If your _delivery schedule_ significantly changes, please also open a pull request with an updated timeline. -- If your deliveries are significantly delayed and we cannot get a hold of you, we will terminate the grant (3 approvals required, regardless of level. If a member of the committee creates the termination PR, only 2 more approvals are required). +- If your deliveries are significantly delayed, and we cannot get a hold of you, we will terminate the grant (3 approvals required, regardless of level. If a member of the committee creates the termination PR, only two more approvals are required). + +## KYB/KYC + +NOTICE: +In connection with your participation in an ecosystem initiative organised by Web 3.0 Technologies Foundation, you agree to the processing of your personal data for identity verification, in order to prevent fraud, ensure eligibility, and maintain the integrity of our processes. This processing is based on legitimate interests under the EU General Data +Protection Regulation and on justified organisational needs under the Swiss Federal Act on Data Protection. Please follow these links to complete the [KYC (Know Your Customer)](https://in.sumsub.com/websdk/p/uni_6qX6Ju3vlfrMQbbG) or [KYB (Know Your Business)](https://in.sumsub.com/websdk/p/uni_6eVGNmoJ83HVovnN) process. Your information will be handled in line with the [Web3 Foundation Privacy and Cookies Policy](https://web3.foundation/privacy-and-cookies/) and the [Sumsub Privacy Notice](https://sumsub.com/privacy-notice-service/). ## :mailbox_with_mail: Suggest a Project -If you think that we should support the development of certain tools or projects that aren't in the Polkadot/Kusama [tech stack](docs/polkadot_stack.md), feel free to submit a suggestion using the process described below. We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem. +If you think that we should support the development of certain tools or projects that aren't in the Polkadot/Kusama [tech stack](https://wiki.polkadot.network/docs/build-open-source), feel free to submit a suggestion using the process described below. We are particularly interested in supporting projects that could be leveraged by other builders in our ecosystem. **Submit an idea:** -If you have an idea for a project or would like to highlight an area in which you'd like to see teams build, but lack the technical background to create a detailed outline, you're welcome to open an [issue](https://github.com/w3f/Grants-Program/issues/new) or add it to the [tech stack](docs/polkadot_stack.md) as a potentially interesting project. We will review your suggestion and, if necessary, will create an RFP based on it and reach out to teams able to build it. +If you have an idea for a project or would like to highlight an area in which you'd like to see teams build but lack the technical background to create a detailed outline, you're welcome to open an [issue](https://github.com/w3f/Grants-Program/issues/new) or add it to the [tech stack](https://wiki.polkadot.network/docs/build-open-source) as a potentially interesting project. We will review your suggestion and, if necessary, will create an RFP based on it and reach out to teams able to build it. **Submit an RFP (Request for Proposals):** Ideas generally have better chances of being implemented if they're presented in a project outline format that can be picked up straight away by a team, so if you have a good concept of the milestones required to bring your project to life, you can follow the process below and directly submit an RFP: 1. [Fork](https://github.com/w3f/Grants-Program/fork) this repository. -2. In the newly created fork, create a copy of the suggestion template ([`rfps/suggestion-template.md`](rfps/suggestion-template.md)) inside the [`rfps`](rfps) folder. Make sure you create a new file and copy the [contents](https://raw.githubusercontent.com/w3f/Grants-Program/master/rfps/suggestion-template.md) of the template into the new one, and _do not modify the template file directly._ +2. In the newly created fork, create a copy of the suggestion template ([`RFPs/suggestion-template.md`](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/suggestion-template.md)) inside the [`rfps`](https://github.com/w3f/Grants-Program/tree/master/docs/RFPs) folder. Make sure you create a new file and copy the [contents](https://raw.githubusercontent.com/w3f/Grants-Program/master/docs/RFPs/suggestion-template.md) of the template into the new one, and _do not modify the template file directly._ 3. Name the file after your idea: `project_name.md`. 4. Fill out the template with the project details. Please include as many details as possible. -5. Once you're done, create a pull request. The pull request should only contain _one new file_—the Markdown file you created from the template. +5. Once you're done, create a pull request in **our** main [Grants-Program repository](https://github.com/w3f/Grants-Program/blob/master/README.md). The pull request should only contain _one new file_—the Markdown file you created from the template. 6. You will see the same template as for creating an application. Please replace it with [this one](.github/PULL_REQUEST_TEMPLATE/rfp_pr_template.md). +7. The RFP will be accepted and merged as soon as it receives three approvals from [W3F Grants Committee](https://github.com/w3f/Grants-Program#w3f-grants-committee) members. ## :hammer_and_wrench: Maintenance Grants @@ -212,35 +287,74 @@ Please note that: - Please bear in mind that the Grants Committee might be stricter in accepting maintainers when compared to typical grants, mostly selecting for applicants with proven experience in the relevant tech stacks. - Maintenance Grants are only awarded for fixed timeframes. The requested duration needs to be specified in the application. +## :moneybag: Referral Program + +We give away 500 USD to each referral of a successful grant application by _anyone having previously worked on a Web3 Foundation grant_ or _a [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors)_. Web3 Foundation and Parity employees do not qualify for the program, even if they previously worked on a grant. + +In order to be eligible for the referral bonus, the application itself must contain the name of the [Polkadot Ambassador](https://wiki.polkadot.network/docs/ambassadors) or the GitHub account of the grantee as well as the payment address for the referral bonus (see the [application template](applications/application-template.md)). Payment is made in USDC on Polkadot AssetHub after delivery and approval of the first milestone. + ## :bulb: Help -### Additional information +### Real-time Conversation -| | | | | | | -| :-: | :-: | :-: | :-: | :-: | :-: | -| [W3F Website](https://web3.foundation) | [W3F Twitter](https://twitter.com/web3foundation) | [W3F Medium](https://medium.com/web3foundation) | [Polkadot Wiki](https://wiki.polkadot.network/en/) | [Web 3.0 Reddit](https://www.reddit.com/r/web3) | [W3F YouTube](https://www.youtube.com/channel/UClnw_bcNg4CAzF772qEtq4g) | +We have a Matrix channel for grant-related questions and activities. Head over there to ask grants-related questions, share your experience with other applications and grantees, or simply hang out: -### Real-time conversation +- [W3F Grants Community](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org) -We have Matrix/Element channels for real-time discussions on Web3 and Polkadot. Join the conversation. +We also have Matrix/Element channels for real-time discussions on Web3 and Polkadot. Join the conversation! - [Web3 Foundation Chat](https://matrix.to/#/#w3f:matrix.org) - [Polkadot Space](https://matrix.to/#/#polkadot:web3.foundation) - [Kusama Space](https://matrix.to/#/#kusama:web3.foundation) -Besides, we also have a **community room for all grant recipients**. Head over to that room to share your experience with other grantees, ask grants-related questions or simply hang out: +### Ecosystem Funding Office Hours + +Ecosystem Funding Office Hours are a chance to ask the W3F Ecosystem Funding team questions regarding a specific project or (potential) grant application. It offers + +- general guidance regarding the various grants programs and prizes, +- some quick initial feedback and +- help how to navigate the ecosystem. + +Apply for Office Hours if you + +- want to find out what kind of support there might be available for your needs, +- need feedback before submitting an application or +- look for help finding other resources you might need. + +It is **not** a chance to _pitch_ your project, especially since only the various programs and prizes have different evaluation criteria and decision makers and only a small subset of the Grants team will participate in the call. To apply, please fill out the [Office Hours :alarm_clock: form](https://forms.gle/54xkiqU37WwdN9UR6). Be as specific as possible, so we can help you more quickly. We will get back to you with follow-up questions or a link for booking a timeslot. -- [W3F Grants Community](https://matrix.to/#/!XpynPDLusWUWfDpaqr:matrix.org?via=web3.foundation&via=matrix.org) ## :rocket: Alternative Funding Sources -Some funding sources might be more and some less suitable for your project throughout its various stages. We encourage you to explore alternative funding options listed below. Please note, however, that you should not seek to fund the **same scope of work** from multiple sources and that any team found doing so will have its Web3 Foundation support terminated. +We encourage you to explore the alternative funding options listed below. Please note, however, that you should not seek to fund the **same scope of work** from multiple sources and that any team found doing so will have its Web3 Foundation support terminated. + +### Treasury vs Web3 Grants + +The following flowchart gives a rough, oversimplified view of how the W3F Grants Program, the Polkadot and Kusama treasuries relate, and where your project might fit best. Note that this diagram does not include any of the [parachain-specific grants/builders programs](#other-grant-programs) other organisations are offering. + +```mermaid +flowchart LR + A(Project Focus) + A -->|Development| B[Stage of Development] + A -->|Research| C[Grants Program] + A -->|Other| D[Treasury] + B -->|Existing POC| E[Goal of the Application] + B -->|No POC| F[Grants Program] + E -->|Funding| G[Treasury or Grants Program] + style C stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 + style D stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 + style F stroke:#e83e8c,stroke-width:2px,stroke-dasharray: 5 5 + + click C "https://github.com/w3f/Grants-Program#pencil-process" "You are already in the right place :)" + click D "https://polkadot.network/treasury" "https://polkadot.network/treasury/" _blank + click F "https://github.com/w3f/Grants-Program#pencil-process" "You are already in the right place :)" +``` ### Treasury The treasury is a pot of on-chain funds collected through transaction fees, slashing, staking inefficiencies, etc. The funds held in the treasury can be spent on spending proposals. Both [Polkadot](https://polkadot.network/) and [Kusama](https://kusama.network/) offer everyone the opportunity to apply for funding via the treasury. See: -- [Treasury Wiki](https://wiki.polkadot.network/docs/en/learn-treasury) +- [Treasury Bounties](https://polkadot.subsquare.io/treasury/bounties) - [Polkadot Treasury Guide](https://docs.google.com/document/d/1IZykdp2cyQavcRyZd_dgNj5DcgxgZR6kAqGdcNARu1w) - [Kusama Treasury Guide](https://docs.google.com/document/d/1p3UQUjph5t8TVaWnTkfrI5mE-BABnM9Xvtuhdlhl6JE) @@ -248,22 +362,24 @@ The treasury is a pot of on-chain funds collected through transaction fees, slas From time to time, Web3 Foundation and/or Parity organise hackathons to promote quick prototyping of Polkadot related ideas. We highly encourage you to participate in these hackathons. Bear in mind, however, that you cannot submit the **same work** for a hackathon and the Grants Program. If you have worked or are planning to work on a project for a hackathon, your grant application should either propose a different set of features or otherwise build on top of your hackathon work. The same applies in reverse, although that will likely be less common. -The best way to find out about upcoming hackathons is by following Polkadot on the various social channels, such as Element or Twitter. +The best way to find out about upcoming hackathons is by following Polkadot on various social channels, such as Element or Twitter. -### Other Grant Programs +### Other Grant or Bounty Programs -Below is a list of other grant programs in the Polkadot/Substrate ecosystem: +Below is a list of other grant and bounty programs in the Polkadot/Substrate ecosystem: -- [Darwinia Grants Program](https://docs.darwinia.network/developers/dev-bounty) +- [Acala Ecosystem Program](https://acala.network/ecosystem-program) +- [Avail Uncharted Grants](https://github.com/availproject/avail-uncharted/blob/main/grants/grants.md) +- [Decentralized JAM](https://jam.web3.foundation/) +- [HydraDX Grants and Bounties](https://docs.hydration.net/community/spending_fw/) +- [ink!ubator](https://use.ink/ubator/) - [Moonbeam Grants Program](https://moonbeam.foundation/grants/) -- [Edgeware Grants and Bounties](https://github.com/edgeware-builders/construction-projects) -- [Crust Grants Program](https://github.com/crustio/Crust-Grants-Program) -- [HydraDX Grants and Bounties](https://docs.hydradx.io/new_deal/) -- [Astar / Shiden Network Builders Program](https://github.com/PlasmNetwork/Builders-Program) -- [Picasso / Composable Grants Program](https://grants.composable.finance) -- [SubQuery Grants Programme](https://subquery.network/grants) -- [Acala Grants Program](https://acala.network/ecosystem-program) -- [OAK’s Developer Grants](https://oak.tech/community/grants/) +- [Moondance Labs Ecosystem Funding Program](https://www.moondancelabs.com/ecosystem-grants-w3f) +- [peaq Ecosystem Grant Program](https://www.peaq.network/grant-program) +- [Pendulum / Amplitude Grant Programs](https://pendulumchain.org/ecosystem-grant) +- [Polkadot Assurance Legion](https://polkadotassurance.com/) +- [Polkadot Open Source Developer Grants](https://github.com/PolkadotOpenSourceGrants/apply) +- [RingDAO Collaboration Hub](https://github.com/ringecosystem/collaboration) ## :information_source: License diff --git a/applications/AdMeta.md b/applications/AdMeta.md index e4e74b0039a..cc770fb9b10 100644 --- a/applications/AdMeta.md +++ b/applications/AdMeta.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# AdMeta -- **Project Name:** AdMeta - **Team Name:** AdMeta - **Payment Address:** 0x1D346c4F0732674a1fc69b4bAFBa854F53353C35 (ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 @@ -127,7 +126,6 @@ Please also provide the GitHub accounts of all team members. If they contain no ### Milestone 1 — Substrate Chain with Impression Ad, Web App - - **Estimated duration:** 6 month - **FTE:** 2 - **Costs:** 12,000 USD diff --git a/applications/Afloat.md b/applications/Afloat.md index ef5ebaa149f..8abbcbfe1f4 100644 --- a/applications/Afloat.md +++ b/applications/Afloat.md @@ -1,22 +1,20 @@ -# W3F Grant Proposal +# Afloat Tax Infrastructure Polkadot Integration -- **Project Name:** Afloat Tax Infrastructure Polkadot Integration - **Team Name:** Afloat Inc. - **Payment Address:** bc1q0aghk8qufzwpmrp5nfyu9r7dh3yynmphk7rhjj - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 - ## Overview [Afloat](https://stayafloat.io/#/) is one of the first real-use cases of blockchain technology in the accounting industry. It enables the fractional buying and selling of tax credits that historically have been inefficient, opaque, and centralized. It has already processed tax credits ranging in orders from $2K -$70k USD. -Afloat was built on a private Ethereum clone but wants to migrate to Polkadot due to its technology, identity management, and community. Parachains like Kilt and their identity services would be crucial at validating government roles and professional certifications like accountants and institutional sellers. +Afloat was built on a private Ethereum clone but wants to migrate to Polkadot due to its technology, identity management, and community. Parachains like Kilt and their identity services would be crucial at validating government roles and professional certifications like accountants and institutional sellers. ## Project Details ### Background -A common tax credit is for land preservation. The inhabitants of a geographic area recognize that their shared quality of life may be positively impacted if more land was preserved rather than developed. If the owner of land property in that area agrees to preserve land, they may be eligible to receive a tax credit in an amount associated with the value of the land property. However, some owners of tax credits do not have enough tax liability to take full advantage of the reward. Because of this, a number of states allow credits to be transferred. State transferable tax credits are typically bought and sold at a discount. +A common tax credit is for land preservation. The inhabitants of a geographic area recognize that their shared quality of life may be positively impacted if more land was preserved rather than developed. If the owner of land property in that area agrees to preserve land, they may be eligible to receive a tax credit in an amount associated with the value of the land property. However, some owners of tax credits do not have enough tax liability to take full advantage of the reward. Because of this, a number of states allow credits to be transferred. State transferable tax credits are typically bought and sold at a discount. Historically, the tax credit industry’s transfer process has been deeply inefficient. Due to a lack of trust between buyers and sellers, accountants and lawyers act as middlemen. This added financial and procedural cost creates an entry barrier for the majority of taxpayers into the tax credit market. What remains is a tight-knit group of wealthy buyers, sellers, and policymakers. @@ -29,29 +27,19 @@ With the ability to tap into a market sector that knows nothing about blockchain Having started in the US, Afloat, Inc., a Wyoming company, is compliant with existing federal, state, and local regulations and takes care of the entire transfer process with the following functions: - Uploading proof of tax credit ownership -

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

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

- -

-
-https://www.investopedia.com/news/majority-us-states-are-still-acknowledge-cryptocurrencies/ \ No newline at end of file + +![Image](https://user-images.githubusercontent.com/7217054/160020643-84313880-4e0b-4942-8b1a-7278eb7aa219.png) + +https://www.investopedia.com/news/majority-us-states-are-still-acknowledge-cryptocurrencies/ diff --git a/applications/AgriDot.md b/applications/AgriDot.md new file mode 100644 index 00000000000..976fba8fb13 --- /dev/null +++ b/applications/AgriDot.md @@ -0,0 +1,215 @@ +# AgriDot - Web3 application for farmers + +- **Team Name:** AgriDot +- **Payment Details:** + - **DOT**: 1ukfa64f2WxSvJy8zwNC2RpSiajt2X1hsYQqBHmM9DTjT8R + - **Payment**: Fiat payment - Details shared on 8. January 2025 at 18:36 via email in the application below. +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 🐣 + +## Project Overview :page_facing_up: +
+AgriDot +

Empowering farmers and beekeepers with blockchain-based NFT field management and community-driven knowledge sharing.

+

+

+

+
+ +AgriDot is an innovative application tailored for farmers and beekeepers, leveraging blockchain technology to enhance agricultural management, increase farmer awareness, and foster community collaboration. The platform enables users many benefits such as: +- Creating and managing their fields as NFTs (Publicly/Privately) +- Field weather monitoring +- Pest tracking (Community shared) +- Sharing valuable agricultural knowledge through guides (Community shared) +- Crop origin proofs (For public fields) + +Both Pests and Guides will also be NFT-based, minted into sovereign collections of AgriDot, moderated by our team. Farmers will be able to donate to other farmers if their Pest report or Guide proves to be useful. + +AgriDot will be fully deployed on Polkadot, fully open source, transparent, and common good, eliminating the need for any databases storing user data. By introducing a novel use case and engaging a unique user base, this project adds to the diversity and utility of the Polkadot ecosystem. + +### Project Details +This proposal presents a solution for integrating an agricultural use case into Polkadot. Currently, there are no other agricultural solutions on Polkadot for comparison. This solution fills a gap by introducing new niche use cases and a niche user base to Polkadot. The solution allows farmers to outsource useful information about their fields, about nearby pests and learn new practices and tips through guides. + +What will Farmers be able to do in the early stage: +- Create a Public/Private field as NFT. + - Public fields are publicly and transparently displayed on Blockchain (NFT explorers are able to easily display them), allowing for crop origin proofs, that farmers can distribute with their crops (Either place them on their products or show them to their business partners). + - Private fields are privately created with NFT metadata hashed by SHA256 (NFT explorers are unable to display NFT metadata, it can only be seen through AgriDot by field owner). This option is available for farmers that want to use application privately. +- See forecast information for any added field (current, hourly & long-term). +- Add pest information for other Farmers with nearby fields. +- See pests, that occurred in nearby locations (Only displaying how far from the nearest field owned by the Farmer wanting to see this information (To keep privacy for private field owners). The maximal search distance can be customized by Farmer. +- Farmers can reward farmers, who publish useful pest information by voluntary donation. +- Add useful agricultural guides (Useful practices, crop cultivation & more). +- See agricultural guides. +- Farmers can reward farmers, who publish useful guides by giving them "like" by voluntary donation. The guides have a simple ranking system and farmers can sort guides by most liked or most recent. +- Farmers can report malicious guides and moderators (Our team) will be able to remove them (Burn the asset on behalf of AgriDot, as all guides and pests are minted under a unified collection (one collection for all pests and one collection for all guides)). +- Farmers can create crop origin proofs by creating crop NFT that is associated with public field. These proofs can help farmers build transparency and trust from their business partners. + +Application advantages compared to traditional Web2 agriculture applications: +- No database with personal details. Everything is stored on the Blockchain transparently. +- Verifiable & immutable crop origin proofs. +- Simple, yet useful blockchain-based Pest report system. + +**UI design proposal** + +The UI of the application is designed to be simple to use and to abstract complexity anywhere possible to provide smooth UX for Farmers. Everything Blockchain/Polkadot related contains simple to understand explanation/guide Farmers can easily follow. Below is an example of a login screen & field overview screen. + +UI + +We have prepared design mockups with simple workflows for the Web3 version in [Figma - here](https://www.figma.com/design/WR2ZtOiYJcq9cBZvRzH4l9/AgriDot). This Figma project also contains the design of our [current PoC](https://github.com/kacena123/aurora-borealis) Web2 solution for comparison. We believe, that the improvement in UI is substantial. + +**Data Models** + +The application utilizes [Kusama Asset Hub](https://parachains.info/details/assethub) as the chain for NFTs (As minting an NFT is a matter of cents on Kusama) and pallet called "NFTs" for concrete operations with collections and NFTs. To query the metadata of NFTs associated with the wallet address of concrete user application uses [Subsquid indexer](https://parachains.info/details/subsquid). The queries for [Subsquid indexer](https://parachains.info/details/subsquid) are created by Kodadot's package called [Uniquery](https://github.com/kodadot/uniquery). + +Below we demonstrate a simple use case of application cold startup, field creation, and crop origin proof creation. + +![agridot field and crop sequential](https://github.com/user-attachments/assets/ac82d2a0-76db-4789-beb3-4bf7af495b02) + +**Technology stack** +- React native +- PolkadotJS +- NodeJS +- Typescript +- Subsquid +- Kodadot Uniquery +- NFTs pallet + +### Ecosystem Fit + +Currently, there are no similar projects within the Substrate/Polkadot/Kusama ecosystem that focus on agriculture and beekeeping using blockchain technology. This distinctiveness positions AgriDot as a pioneering project in this domain. + +There are some agricultural projects in other blockchain ecosystems, however, none have successfully integrated the unique features of NFTs and decentralized community collaboration in the way AgriDot aims to achieve. + +While the main target audience of this project are Farmers and Beekeepers, other users may find the availability of useful Guides and even Pest reports (If they have small fields at home) very useful. While benefits, that AgriDot gains by enhancing Blockchain technology are substantial, the farmers are often not that technical and need to be shown, that the blockchain can be useful for them. This is why the application will notify them, that the data is transparently stored on the Polkadot blockchain and that the application does not collect nor will need to collect any data from them. + +The application bridges an important gap in niche user base and niche use case, that has not yet been explored on Polkadot by anyone. + +We have created a survey that was sent to 300 small and medium Agricultural businesses in Slovakia to gain insight on whether Farmers will be open to such an application and if so, if they will be willing to accept, that it will use Blockchain to enhance transparency. We received an overwhelming amount of responses from 167 farmers, that an application like this is very needed and they also provided us with feedback as to what should the application contain. We share the experiment results below. + +![chart1](https://github.com/user-attachments/assets/f42530a8-2bdc-458d-8ebd-6302f3e47316) + +First, we asked Farmers which listed features would they like to see in the ideal Agricultural application. The most useful for them is by far the weather monitoring. They also highly ranked Pest information and crop origin proofs. Based on this we then designed the application to fit most of the Farmer's needs. + +![chart2](https://github.com/user-attachments/assets/441dfc2c-9675-4cf6-bfab-bf67e0be4b38) + +In the second question, we asked Farmers if they would be open to Blockchain-based application that would enhance transparency of how their data is handled. More than 120 farmers stated, that they are open to this innovation and the rest of the farmers stated, that they are not open or that they are not sure which means, that the Farmers, that stated that they are not sure could change their mind once they try the application. + +### Related work + +**AgriApp** + +AgriApp is an Indian Web2 application for farmers - [Web](https://agriapp.com/), [Google Play](https://play.google.com/store/apps/details?id=com.criyagen&hl=en_US). It offers a range of features, including crop monitoring, advice on fertilization, irrigation, pest control, soil analysis, and weather forecasting. It also includes tools for managing work schedules, planning maintenance, and tracking costs and revenues. Additionally, the app features a store where users can purchase various pesticide products and fertilizers. Some advanced features are available only in paid versions of the app, which entails additional costs. Given the app's extensive functionality, it may be complex for new users, and fully utilizing its features may require some time to learn compared to AgriDot which is designed to focus on user-friendliness, meaning that even new users can quickly navigate and use the application without extensive training. Another downside is, that AgriApp does not have open-source code and users are unable to verify if their data is not used for malicious practices or sold compared to AgriDot which doesn't store any user data and has fully open-source code. + +**Agrichain** + +The AgriChain Web3 application is a tool aimed at improving transparency and efficiency in the agricultural sector through blockchain technology - [Web](https://agrichain.com/ +), [Google Play](https://play.google.com/store/apps/details?id=com.agrichain&hl=sk +), [Research article](https://link.springer.com/chapter/10.1007/978-3-030-96527-3_1). Its main advantage is the ability to track every stage of the supply chain, which allows accurate recording of transactions and the origin of products. In this way, the application tries to increase trust in the quality and safety of food. +AgriChain's user interface is intuitive and easy to use, allowing even less experienced users to effectively manage their operations. The application also provides analytical tools to optimize production and manage inventory and payments through smart contracts. +Agrichain primarily targets large farmers and large supply chains. Smaller farmers and beekeepers may find it much more difficult and costly to implement AgriChain into their production. Agrichain places great emphasis on supply chain efficiency and transparency and focuses mainly on management, while not supporting other functions such as weather, pest monitoring and also community functions between individual farmers compared to AgriDot. + +**AgriDigital** + +AgriDigital Onfarm is a Web3 application designed for modern farmers that simplifies and optimizes the management of agricultural production - [Web](https://www.agridigital.io/), [Google Play](https://play.google.com/store/apps/details?id=io.waypath.app&hl=sk&gl=US). It is part of the AgriDigital ecosystem, which focuses on the digitization and streamlining of Agricultural business. The application allows farmers to manage and monitor the warehouse and also manage the sale of stocks of cultivated crops. It enables detailed management of landlord distributions and profit shares, thus ensuring transparency in the distribution of income. AgriDigital Onfarm generates detailed reports on total yield per specific field, as well as gross yield at the farm and individual field levels, enabling performance analysis at various levels. It has an intuitive interface, which makes it easy to use even for less technical users. Its main goal is to increase the efficiency and performance of farms using analytical tools. The main downside of AgriDigital compared to AgriDot is, that AgriDigital is not available in all countries and its services are not free. The AgriDigital application focuses more on managing crop sales and farmer finances. It does not offer functionality such as weather monitoring, or pest control and does not support a community system. + +## Team :busts_in_silhouette: + +### Team members + +- Katarína Valová - Core developer, Master's degree student Faculty of Informatics and Information Technologies STU in Bratislava, Slovakia + +### Contact + +- **Contact Name:** Katarína Valová +- **Contact Email:** valova.katarin@gmail.com + +### Legal Structure + +- **Registered Address:** Stošická 472, Liptovský Mikuláš 03104, Slovak Republic +- **Registered Legal Entity:** Katarína Valová + +### Team's experience + +Katarína is studying Master's degree at the Faculty of Informatics and Information Technologies STU in Bratislava, her Bachelor's thesis was about creating application meant to ease farmers' lives by providing them key information about their fields and pests. Katarína was recently introduced to Web3 by her new university Master's thesis supervisor [Dušan](https://github.com/dudo50). She found out, that she is very passionate about transforming Web2 applications into Web3 applications, making them much less resource-dependent and more transparent. Katarína found passion in writing research articles about this topic and participated in the local university conference. Katarína also sees this as an opportunity to introduce a new niche use case to Polkadot and she is very excited to explore this ecosystem further and expose it to farmers. + +### Team Code Repos + +- https://github.com/kacena123/aurora-borealis + +### Team Github Profiles + +- https://github.com/kacena123 + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/katka-val/ + +### Advisors +Ecosystem developers who agreed to provide advisory help during the project implementation phase: + +- Dudo50 founder of ParaSpell (Interoperability solutions) + +## Development Status :open_book: + +Currently, there is a PoC called [Aurora Borealis](https://github.com/kacena123/aurora-borealis) developed and ready to be used as a Web2 application in Kotlin. The enhanced version will be programmed in a more widely used React Native framework, and have a complete design overhaul and Web3 migration. + +We have created Figma mockups of how would this Web2 to Web3 migration look. They were mentioned in the project details but we will link them here too - [figma link](https://www.figma.com/design/WR2ZtOiYJcq9cBZvRzH4l9/AgriDot). + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 months +- **Full-Time Equivalent (FTE):** 1 +- **Total Costs:** 10,000 USD +- **DOT %:** 50% + +### Milestone 1 - Working Web3 solution - AgriDot + +- **Estimated duration:** 4 month +- **FTE:** 1 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** on how to interact with the application from registration to interaction with the blockchain. | +| **0c.** | Testing and Testing Guide | We will provide unit tests for core application functionality. Guide on how to launch these tests will be mentioned in the README.md | +| **0d.** | Docker | We will provide a docker file that will let you try all the implemented functionality mentioned in the milestone description. | +| 0e. | Article | We will provide a summary article that will mention all the innovations brought during the development of AgriDot. This article will be published on [Medium](https://medium.com/). | +| 1.a | Fields as NFTs (Private) | We will implement functionality that allows farmers to mint their fields as NFTs (via "[NFTs](https://wiki.polkadot.network/docs/learn-nft-pallets#nfts-pallet)" pallet) in a secure, hashed way (in-app hashed by AgriDot key phrase (each NFT will be checked for the correspondation between signed wallet address and owner of NFT before being decoded and displayed (as additional protection step))) so only AgriDot will be able to decode them and display them to farmers who own them. | +| 1.b | Fields as NFTs (Public) | We will implement functionality that allows farmers to mint their fields (via "[NFTs](https://wiki.polkadot.network/docs/learn-nft-pallets#nfts-pallet)" pallet) in a public way, so any NFT explorer will be able to display them (NFTs will have a standard format (name, image, metadata(containing field coordinates) )). These fields will then be able to be used with "4. Crop origin proofs" allowing farmers to create a proof of crop origin that will be linked to their public field. | +| 1.c | See the weather for your NFT fields | We will implement functionality that lets you query the coordinates of your NFT fields and display weather for the upcoming period (This feature will use [Kodadot uniquery](https://github.com/kodadot/uniquery) package for creating queries that will be used with [Subsquid indexer](https://www.sqd.dev/). Weather for farmer's NFTs will be queried from [Open-Meteo](https://open-meteo.com/) open-source API (or else if found better)) | +| 2.a | Pests as NFTs | We will implement Pest functionality. Pests will be minted to a unified collection (via "[NFTs](https://wiki.polkadot.network/docs/learn-nft-pallets#nfts-pallet)" pallet), with coordination of the Field where it appeared (Coordinate will be private (Hashed in-app by AgriDot key phrase)), farmers will only know, that a certain Pest appeared X km away from their field (They will be able to set how far they wish to monitor pests) | +| 2.b | Donation system for Pest reporters | We will implement a donation system for pest reporters. Farmers that actively report Pests and are useful to the community can receive donations from Farmers who are willing to thank them for this information (Potentially saving their crops & giving them the ability to prepare for Pest arrival well ahead). This feature will use a standard transfer pallet. | +| 3.a | Guides as NFTs | We will implement guides to be mintable as NFTs into the unified collection (via "[NFTs](https://wiki.polkadot.network/docs/learn-nft-pallets#nfts-pallet)" pallet). Guides allow farmers to share their knowledge with other farmers (They can range from DIY guides to crop-growing or animal caretaking guides). | +| 3.b | Rating and donation system for Guides | We will implement functionality that allows farmers to provide guide rating by small donation to Farmer who created the Guide. The application will display the amount of "Likes"(Donations) and a report button (So malicious guides can be removed by administrators). This functionality requires a database, however only for 2 anonymous details (Concrete guide NFT ID & amount of times, that farmers donated (Not saving who (which address donated). The database will only increase like a counter once the donation is finalized in the block also). This feature will use a standard transfer pallet. | +| 4. | Crop origin proofs | We will implement a feature that allows farmers to mint NFTs of crops (via "[NFTs](https://wiki.polkadot.network/docs/learn-nft-pallets#nfts-pallet)" pallet), that were cultivated on field that farmer minted. Farmer will then be able to use these NFTs as proof of crop origin. The application will generate a QR code for NFT explorer that will contain details about the crop and its origin field (If the field was minted as Public). | +| 5.a | Comprehensive documentation I | We will provide comprehensive documentation for developers - on how to start the application and different functions overview (Via GitHub pages) | +| 5.b | Comprehensive documentation II | We will provide comprehensive documentation for users - on how to create a Polkadot wallet, how to use the application, and a basic application overview (Via Github pages) | + + +## Future Plans + +The application is and will be a common good, further living from donations made by farmers - We will implement voluntary donations for certain features so they can support the application if they would like to. As server costs will be minimal (Due to the lack of a complex database & full use of on-chain storage) this shouldn't be an issue to achieve. The application will strictly not contain any ads. As for innovations, we would like to focus on a few key areas in the Polkadot network further on: +- Adding support for managing animals (Same way, that fields are managed) and adding proofs of origin for products that are produced by animals/from animals. +- Implementing schedules feature (To allow farmers to create simple schedules to structure their work) +- Adding support for notifications regarding Pests or Weather (It can help farmers notice problems faster) +- Simple crop/products marketplace +- Creating a simple on-chain storage pallet (To further enhance Guides, allowing for larger texts and sub-sectioning). +- Building Parachain focused on Farmers and Agriculture (There are many great use cases that can help ease farmers' lives). + +These innovations will drive the next wave of digital transformation in agriculture. + +As for gaining users, we will notify the contacted farmers about the application & we plan to contact farmers in other states through agriculture festivals and +agricultural technology exhibitions. + +## Referral Program :moneybag: + +- **Referrer:** [Dudo50](https://github.com/dudo50) +- **Payment Address:** 139zHfuPsG62FKQtwjxMwqZAwPNZG6BooUWgF6L3LWYLUu3z (Polkadot) + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Personal recommendation by the university thesis supervisor. + +The main problem Farmers seem to have with Blockchain is a lack of trust in this technology. We would like to prove them otherwise and explain to them in the simplest way possible, that this technology is very useful in various use cases that we wish to explore and bring to them throughout their (and our) journey with AgriDot. diff --git a/applications/Aisland-DocSig.md b/applications/Aisland-DocSig.md new file mode 100644 index 00000000000..03dbe5c7aa9 --- /dev/null +++ b/applications/Aisland-DocSig.md @@ -0,0 +1,241 @@ +# Aisland Docsig + +- **Team Name:** AISLAND DAO +- **Payment Address:** 0x78A4C8624Ba26dD5fEC90a8Dc9B75B4E3D630035 USDC/Ethereum +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +## Project Overview :page_facing_up: + +### Overview + +Aisland DocSig allows to e-sign documents, exchange easily and store permanently on chain as legal proof. +POC/MVP is available at [https://docsig.aisland.io](https://docsig.aisland.io) +Faucet for testing: [https://testnet.aisland.io:8443](https://testnet.aisland.io:8443) + +Aisland DocSig (in short ADC) solves the problem of exchanging signed agreements and storing them permanently with legal validity. The user can authenticate using his/her own wallet, create a blank document and edit, or clone a public template or upload a document. +ADC keeps a copy of the different drafts till the first signature is applied. +A secret link is generated to request the signing to the counterpart. +The workflow provide visibility on the different status of the documents: Draft, Waiting (for signing), Completed (all parties have signed), Rejected (one party rejected it). + + +There is no e-signing documents solution in the Polkadot/Kusama echo-system, instead there are all the layers to create something better of commercial services. In the web2 world, https://docusign.com declares about 200 million paying user and > 1 billion users who used their platform. + +[Aisland Dao](https://aisland.io) is an experimental micro-nation with a small territory of 14000 square feet. Aisland is based on a deck barge floating in international waters since 22 December 2022 in the Arabian Gulf. +The current small territory can be increased with additional barges properly interconnected. +The main purpose of Aisland Dao is to give full sovereignty to the individual and a real place where the wider principles of freedom are applied. +The decentralized e-signing of documents is one of the many tools that every free and sovereign person should have the right to use. + + +### Project Details + +Preface: +We have already developed a minimum viable product (MVP) that is available at [https://docsig.aisland.io](https://docsig.aisland.io). The current MVP is offering the following features: + +- Dashboard to manage the workflow +- Create/Edit a document on-line using the block editor (editor.js). +- Clone a public Template and Edit. +- Upload a document in different formats. +- Sign the document. +- Generate unique link to allow the signing of the counterpart. +- View on-line the documents +- Delete the document in drafts +- Rejects the signature on proposed documents for signing. +Here the workflow: +![Workflow](https://github.com/aisland-dao/docsig/blob/main/img-docs/docusign-workflow.png) + +Here a few screenshots: +![Dashboard](https://github.com/aisland-dao/docsig/blob/main/img-docs/docusign-dashboard.png) +![Operations](https://github.com/aisland-dao/docsig/blob/main/img-docs/docusign-operations.png) +![Blank Document](https://github.com/aisland-dao/docsig/blob/main/img-docs/docusign-blankdocument.png) +![Signing](https://github.com/aisland-dao/docsig/blob/main/img-docs/docusign-signing.png) + + +The project proposal consists in adding a new set of features to make a production ready version, comparable to the best WEB2 solution offering like https://docusign.com. Here is the list of the new features to be added: + +1) Standard Signatures Management to allow the user to set his own standard signature image. +2) Signature Marker, to allow the placing of signatures on the document for a visual improvement. +3) Document Encrytion, to manage the privacy of the documents even when saved on chain. +4) PDF output of the signed agreement with verifiable QR code. +5) Storage of the encrypted documents on the blockchain. +6) Enhanced link sharing, to forward the signing link by different communication channel. +7) Multiple Counter Parties, to manage the signature of > 2 parties on the same document. +8) Enhanced templates, to manage also private templates. + +Technology Stack: +- The blockhain side is based on a custom pallet named [docsign](https://github.com/aisland-dao/aisland-node/tree/main/pallets/docsig). + +- The [Dapp](https://github.com/aisland-dao/docsig) is built on HTML,CSS and vanilla javascript for the client side. It's built with Javascript/Nodejs for the Server component. It's working with Polkdatot Extension and Subwallet. + +Requirements: +- Nodejs +- Mariadb Server + +The MARIADB will be used to store only the workflow data and the signed documents will be encrypted and stored on chain for permanent storage. + +### Details of the Proposal +Here is the list of deliverables new features in much more details: + +1) Standard Signature Image - Manage the setting of the standard signature image, selecting from multiple auto-generated signatures or one uploaded. The Dapp shwillould auto-generate multiple style of signatures starting from a text using cursive fonts. +We will use a set of 50 cursive fonts to generate the signature image. A considerable selection of free cursive fonts are available here: [https://www.1001fonts.com/cursive+signature-fonts.html](https://www.1001fonts.com/cursive+signature-fonts.html). +The upload of a scanned image in png/jpg/webp or svg format is not a challenge. +Here is an example: +![Signature Example](https://github.com/aisland-dao/docsig/blob/main/img-docs/docusign-standardsignatures.png) + + +2) Signature Marker - We will create a plugin for editor.js to mark the place where the signatures shall be placed. Once the document is signed, the selected signatures will be shown in the document. +[https://editorjs.io/](https://editorjs.io/) is a free block editor for javascript that is composable by plugins. We used such editor in the current MVP. It save the document in a clean json format. +Here is an example: +![Signature Example](https://github.com/aisland-dao/docsig/blob/main/img-docs/docusign-signatureexample.png) + + +3) Encryption - For enhanced privacy the documents and other metadata shall be encrypted as follows: +- The files will be encrypted using AES256-GCM and Chacha20 as symmetric cyphers in cascade and a random private key of 512 bit. The symmetric private key will be encrypted by the asymmetric public key of the user. The user will be able to decrypt using his/her own asymmetric public key. +- The documents to be signed from the counter part shall be encrypted with a random private key and the same shall be encrypted with the public key of the recipient. The recipient will be able to decrypt using his/her own asymmetric private key. +- The Dapp must manage the settings of the initial asymmetric public/private keys. +- The open source library that we will use is libsodium which offers the necessary primitives: +[https://doc.libsodium.org/](https://doc.libsodium.org/) +[https://www.npmjs.com/package/libsodium](https://www.npmjs.com/package/libsodium) + +4) Documents Storage - We will optionally store on-chain the signed contracts. We wish to give immutability of whole document even if it's little bit more expensive. Actually the MVP is storing only the hash of the document and keeping the document in the server storage. The pallet will be modified to accept the storage of an encrypted binary blob with some limitations in size to be configured in the pallet itself. +We will add 2 functions to the current pallet: newBlob(id,documentdata), deleteBlob(id) + +5) Pdf Output - The dapp should be able to generate a contract with the visual signatures and a QR code to verify on chain the validity of the contract. This is a legal requirement to let use the document in court. + +6) Link Sharing - The dapp shall allow the sharing of the signing link by: email, Matrix, Whatsapp, and Telegram. + +7) Multiple Counter Parties - The current MVP does support only 2 signing parties, we will refactor the Dapp to manage multiple signing parties. + +8) Enhanced Templates - The MVP allows to select a template from a system list. We wish to allow the user to create his/her own private templates. + +### Ecosystem Fit + +- Where and how does your project fit into the ecosystem? +The proposal creates a general purpose utility for the wide public in using Substrate technology. + +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? +Any web3 user or legala entity have to exchange contracts during the course of life. +- What need(s) does your project meet? +E-signing of documents, permanently storage and easy exchange of the same. +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? +We have not been able to find something similar in the echo system. + - If so, how is your project different? + - If not, are there similar projects in related ecosystems? + [https://www.sign.co/](https://www.sign.co/) + [https://www.jsign.com](https://www.jsign.com) + [https://www.cygnature.io](https://www.cygnature.io) + [https://www.corposign.net/](https://www.corposign.net/) + +## Team :busts_in_silhouette: + +### Team members + +- Name of team leader +Achille Landi +- Names of team members +Samuele Landi + +### Contact + +- **Contact Name:** Achille Landi +- **Contact Email:** admin@aisland.io +- **Website:** [https://aisland.io](https://aisland.io) + +### Legal Structure + +- **Registered Address:** Unit No: 1508,DMCC Business Centre, Dubai - United Arab Emirates +- **Registered Legal Entity:** Samra Consulting dmcc + +### Team's experience + +Achille Landi is the lead developer of Aisland with experience in Rust and Javascript +Samuele Landi is a long term developer for secure communications and web3 projects. + +### Team Code Repos + +- [https://github.com/aisland-dao/aisland-node](https://github.com/aisland-dao/aisland-node) +- [https://github.com/aisland-dao/dex](https://github.com/aisland-dao/dex) +- [https://github.com/aisland-dao/docsig](https://github.com/aisland-dao/docsig) +- [https://github.com/aisland-dao/aisland-store-web-server](https://github.com/aisland-dao/aisland-store-web-server) (private repo we can give access) + +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/poseidon-aisland +- https://github.com/samuelelandi + +### Team LinkedIn Profiles (if available) + +- not available +- not available + + +## Development Status :open_book: + +We have already developed a POC/MVP with a dedicate pallet on Substrate: +[https://github.com/aisland-dao/aisland-node/tree/main/pallets/docsig](https://github.com/aisland-dao/aisland-node/tree/main/pallets/docsig) + +and a Dapp: +[https://github.com/aisland-dao/docsig](https://github.com/aisland-dao/docsig) + +An live demo is available at: +[https://docsig.aisland.io](https://docsig.aisland.io) + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 1.5 FTE +- **Total Costs:** 9000 USD + +### Milestone 1 Example — Basic functionality + +- **Estimated duration:** 1 month +- **FTE:** 1.5 +- **Costs:** 4500 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how to start the node and run the Dapp | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. The language will be English and it will be published also in our media channels | +| 1. | Substrate module: pallet-docsig | We will implement the current pallet-docsig to allow the storage on chain of the documents within certain size limits | +| 2. | Dapp Feature: Standard Signature Image |We will add the new feature to manage the standard signatures as described at the point 1 of "Details of the Proposal"| +| 3. | Dapp Feature: Signature Marker | We will create a plugin for editor.js to allow the placing of the signature marker as described at the point 2 of "Details of the Proposal"| +| 4. | Dapp Feature: Encryption | We will implement the encryption as described at the point 3 of "Details of the Proposal"| + + +### Milestone 2 - Additional Features + +- **Estimated Duration:** 1 month +- **FTE:** 1.5 +- **Costs:** 4500 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how to start the node and run the Dapp | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. The language will be English and it will be published also in our media channels | +| 1. | Dapp Feature: Pdf Output|We will add the new feature to generate a pdf output as described at the point 5 of "Details of the Proposal"| +| 2. | Dapp Feature: Link Sharing | We will add a function to share the link for signature as described at the point 6 of "Details of the Proposal"| +| 3. | Dapp Feature: Multiple Counter Parties | We will reafactor the Dapp to allow the signature from different parties as described at the point 7 of "Details of the Proposal"| +| 4. | Dapp Feature: Enhanced Templates | We will add the feature to create/manage private templates into the Dapp as described at the point 8 of "Details of the Proposal"| + + +## Future Plans + +- We will add the possibility to make escrow payments in the execution of the agreements signed. +- We will add a decentralized arbitration service in case of litigations to be settled. +- We wil promote the docsig within the Web3 and Seasteader community. Aisland has signed an agreement with Liberland to develop a bigger floating city from this outpost and we will push to let become DocSig the standard method to sign agreements: [https://liberland.org/en/news/434-memorandum-of-understanding-with-aisland](https://liberland.org/en/news/434-memorandum-of-understanding-with-aisland) +Aisland Dao will develop other Dapp to help the transiction from web2 to web3. + +## Referral Program (optional) :moneybag: + +Not applicable + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/AlgoCash.md b/applications/AlgoCash.md index f2db43a9dc4..97caad34f15 100644 --- a/applications/AlgoCash.md +++ b/applications/AlgoCash.md @@ -1,13 +1,11 @@ -# Open Grant Proposal +# AlgoCash > This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/blob/master/README_2.md) on how to submit a proposal. - - -* **Project Name:** Algo Cash * **Team Name:** Reserve Labs * **Payment Address:** DAI Address: 0x3f91475fbd0c3d9c676d39af071691c1cf635f0b -## Project Overview + +## Project Overview ### Overview @@ -25,15 +23,13 @@ Algo Cash is implemented as a smart contract which can be deployed into ink! pal For trading and liquidity purpose, Algo Cash could be integrated with such protocols in Polkadot as Konomi and Zenlink. - -## Project Details +## Project Details ### Tokens #### ALC - Algo Cash -Algo Cash tokens are designed to be used as a medium of exchange. The built-in stability mechanism expands and contracts their supply, maintaining their peg to the aUSD token. - +Algo Cash tokens are designed to be used as a medium of exchange. The built-in stability mechanism expands and contracts their supply, maintaining their peg to the aUSD token. #### ALB - Algo Bonds @@ -67,7 +63,6 @@ Every 24 hours, the time-weighted average of the ALC-aUSD exchange rate is read The stabilization mechanism is triggered whenever the price of Algo Cash is observed to be above / below (1+ε) aUSD, where ε is a parameter that defines the range of price stability for the ALC token. In inilization, ε is set to be 0.05. - #### Contractionary Policy At any point in time, Algo Bonds can be bought from the protocol in exchange for Algo Cash. Purchase of Bonds are performed at an algorithmically set price. With a Algo Cash oracle price of P aUSD, bonds are sold off at a price of P ALC (effective price being P^2 aUSD), promising bond holders a premium when redeemed. Purchased bonds can be converted to Algo Cash, insofar as the preconditions are met and the Treasury is not empty. @@ -104,26 +99,22 @@ Advantages **cash - Minting and burning of the cash token** -Mints *amount* cash to the *recipient* account. +Mints *amount* cash to the *recipient* account. Burns *amount* cash from the *account*. - **bond - Minting and burning of the bond token** -Mints *amount* bond to the *recipient* account. +Mints *amount* bond to the *recipient* account. Burns *amount* bond from the *account*. - - **share - Minting and burning of the share token** -Mints *amount* share to the *recipient* account. +Mints *amount* share to the *recipient* account. Burns *amount* share from the *account*. - **Treasure - Bond purchase and redemptions** Returns the oracle price of Algo Cash denominated in aUST. @@ -134,7 +125,6 @@ Mints *amount* Algo Cash, in exchange for *amount* Algo Bonds burnt. If the oracle price of Algo Cash is above (1+ε) aUST, mints *((ALC Oracle Price) - 1) * cashSupply* number of Algo Cash to either the Boardroom contract or the Treasury contract.If the Treasury's balance is below 1,000 ALC, the allocation is given to the Treasury, else give it to the Boardroom. - **Boardroom - Handling claims from the share** Stakes *amount* Algo Shares to Boardroom sends all prior accrued dividends to *account*. @@ -147,56 +137,59 @@ Claims all accrued dividends to *account*. When new cash is assigned to the Boardroom contract. Records the current block timestamp, the amount of new cash, and the current amount of total Shares staked. - **oracle - Retrieving the exchange rate between Algo Cash and aUST** -If 24 hours has passed since update() was last successfully executed, updates the time-weighted average price of Algo Cash. +If 24 hours has passed since update() was last successfully executed, updates the time-weighted average price of Algo Cash. Returns the amount of *output* tokens given in exchange for *input* number of *token* tokens ((Price of *token* token denominated in *output* tokens) * *input*). +### Ecosystem Fit - - - -### Ecosystem Fit Acala, aUSD is generated in a collateral way. Basis Cash (on Ethereum), shares are initialized by 'AMM + 2nd pool' which would cause dramatic infaltion, forcing Yeild Farmers to sell their assets to the second market. -## Team +## Team ### Team members + * Nick Hsu, Blockchain Expert and Team Leader -* Gang Chan, Full Stack Developer +* Gang Chan, Full Stack Developer * Gieno Miao, Crypto Expert and Blockchain Architect ### Contact + * **Contact Name:** Nick Hsu * **Contact Email:** nick_hsu@sina.com +### Legal Structure -### Legal Structure No legal Entity ### Team's experience + Nick has 16 years of software development experience and 5 years working in Blochain area as developer and product owner. Gang is now working as a freelancer. He is a full stack developer proficient in C++, Rust, React and Solidity. He has 3 years software development experience and 2 years smart contract development experience. ### Team Code Repos + * https://github.com/ReserveLabs/AlgoCash ### Team LinkedIn Profiles + no +## Development Roadmap -## Development Roadmap ### Overview + * **Total Estimated Duration:** 6 weeks * **Full-time equivalent (FTE):** 1.5 * **Total Costs:** 5,000 DAI -### Milestone 1 Example — Implement Substrate Modules +### Milestone 1 Example — Implement Substrate Modules + * **Estimated Duration:** 7 weeks * **FTE:** 2 * **Costs:** 5,000 DAI @@ -206,15 +199,15 @@ no | 0 | License | Apache 2.0 / MIT / Unlicense | | 1 | Documentation | Specification of the background, components and working mechanism| | 2 | Smart Contract | AlgoCash smart contract repo. The smart contract can be deployed to any substrate chain with ink! pallet.| -| 3 | Tests |Unit Test and also we will test it on Canvas| +| 3 | Tests |Unit Test and also we will test it on Canvas| | 4 | Docker | A docker image with a Substrate chain for PoC| - - ## Future Plans + Shares token design for governance. We will build a DEX with PMM (Proactive Market Maker) algorithm. ## Community Engagement -We will reach DEX and Lending protocol communities to enlarge Algo Cash adoption. + +We will reach DEX and Lending protocol communities to enlarge Algo Cash adoption. diff --git a/applications/Anchor.md b/applications/Anchor.md new file mode 100644 index 00000000000..86a6777a936 --- /dev/null +++ b/applications/Anchor.md @@ -0,0 +1,286 @@ +# Anchor, On-chain Linked List pallet and Name Service + +- **Team Name:** Fuu +- **Payment Address:** 13u5kLGrt4n1Smc78ZXtYVedgp1U1LyGAAHtPFtVcv6Z1BtR (USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + + +## Project Overview :page_facing_up: + +### Overview + +- Anchor is a on-chain linked list system base on substrate 3.0.0. It is used to support cApp ( Chain Application ) development. On another hand, Anchor can alse be treated as Name Service or on-chain key-value storage system. + +- Anchor is a isolated substrate pallet. It is currently used in the application of freeSaying. It can provide flexible data structure on the chain and handle complex logic without upgrading the substrate node itself. +You can access the [freeSaying ( Only applicable to mobile )](https://freesaying.net) demo to know well. Anchor network is the very important basic storage system. Anchor.js is a isolate JS library to access Anchor network, can read and write data easily. +Anchor pallet is a part of EasyPolka, the relationship as follow : + +![easypolka.png](http://android.im/anchor/easypolka.png) + +QR to access to freesaying.net. +![easypolka.png](http://android.im/anchor/qr.png) + +- With Anchor, you can use run a substate network just need a bit upgrade. Through the highly customizable data structure and the ability of cApp, the threshold of application development on the chain is greatly reduced. It means that new developers who even does not know blockchain well can build cApp just by Javascript and publish it nearly free. + +- As a web developer, I firmly believe in the future of blockchain technology, but when I turn to blockchain development, I encounter a huge threshold. It takes a lot of time to get familiar with both language and various concepts. At the same time, technology is still improving, and a stable development environment cannot be obtained. All of these prompted me to improve EasyPolka for my own development. +So far, only one person myself can develop complex cApp ( on-chain applications ). I believe that this can help other developers to build cApps more efficiently. +Will try to apply the left part, it is a bit complex, I am working on regrouping them now. The image show the whole structure. + +![easypolka.png](http://android.im/anchor/easypolka_not.png) + +### Project Details + +- Anchor development itself has been done, and it is deployed here [check "wss://dev.metanchor.net" on polkadot.js.org](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fdev.metanchor.net#/explorer). One cApp is deployed to test too, the URL is [https://freesaying.net](https://freesaying.net). This React project load the target Anchor "freeSaying" from dev.metanchor.net, then run the cApp which is a socail media application. + +- There are 4 methods and 2 stores to implement the on-chain linked list function in Anchor pallet. + +- Substrate 3.0.0 and Rust for Anchor pallet. Javascript for anchor.js. + +- Code here [https://github.com/ff13dfly/Anchor](https://github.com/ff13dfly/Anchor), the document is the next step. + +- Treat Anchor as Name Service, there is no available pallet can be use. Have checked here [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source). +![easypolka.png](http://android.im/anchor/status.png) + +- The function of Anchor has been finalized and will not be further expanded on substrate side. The function of the current version is the final form. + +### Ecosystem Fit + +- An available Name Services on Substrate 3.0.0, and it is extended to a On-chain Linked List system. + +- Developers who have not yet used substrate/Polkadot. Developers who do not like Smart Contract way to develop application. + +- Developer can build application flexibly without understanding the whole blockchain system. I think this is attractive to many developers. + +- From the [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source), there are 4 Name Service pallets, 2 red ( can not compatible to substrate 3.0.0 ) and 2 yellow ( code not updated more than 2 months by checking github ). + +## Team :busts_in_silhouette: + +### Team members + +- Zhongqiang Fu, individual developer. + +### Contact + +- **Contact Name:** Zhongqiang Fu +- **Contact Email:** ff13dfly@163.com +- **Website:** https://github.com/ff13dfly/ + +### Legal Structure + +- Individual + +### Team's experience + +- On substrate, Substrate with Anchor pallet has been build successful and run at [wss:dev.metanchor.net](wss:dev.metanchor.net). I have tried to load a three nodes network successful. + +### Team Code Repos + +- https://github.com/ff13dfly/ +- https://github.com/ff13dfly/Anchor + +### Team LinkedIn Profiles (if available) + +## Development Status :open_book: + +- Demo cApp [freeSaying](https://android.im/vManager/) is published now. The test network is available, you can access [wss:dev.metanchor.net](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fdev.metanchor.net#/explorer). Anchor pallet functions have been developed, but not tested entirely. + +## Development Roadmap :nut_and_bolt: + +### Anchor pallet + +- There are 4 methods exposed. One for setting data, Three for trading anchor. + ![easypolka.png](http://android.im/anchor/methods.png) + 1. setAnchor, set Anchor data method. + + ```RUST + pub fn set_anchor( + origin: OriginFor, //default + key: Vec, //Anchor name + raw: Vec, //raw data to storage + protocol: Vec, //data protocol, used to decide how to decode raw data + pre:T::BlockNumber //the previous block number which storage anchor data + ) -> DispatchResult { + // code here. + Ok(()) + } + ``` + + 2. sellAnchor, sell your Anchor publish or to target account. + + ```RUST + pub fn sell_anchor( + origin: OriginFor, //default + key: Vec, //Anchor name + cost: u32, //unit accuracy + target:::Source //target buyer SS58 address. If the same as owner, can be sold to anyone. + ) -> DispatchResult { + // code here. + Ok(()) + } + ``` + + 3. unsellAnchor, revoke Anchor sell status. + + ```RUST + pub fn unsell_anchor( + origin: OriginFor, //default + key: Vec, //Anchor name + ) -> DispatchResult { + // code here. + Ok(()) + } + ``` + + 4. buyAnchor, buy target Anchor which is on sell. + + ```RUST + pub fn buy_anchor( + origin: OriginFor, //default + key: Vec, //Anchor name + ) -> DispatchResult { + // code here. + Ok(()) + } + ``` + +- There are two Runtime Storage. One for the anchor data status, one for the on-sell list. + ![easypolka.png](http://android.im/anchor/storage.png) + ```RUST + // (T::AccountId,T::BlockNumber) + // T::AccountId, the anchor owner ss58 address + // T::BlockNumber, last block number when updated data successfully. + pub(super) type AnchorOwner = StorageMap<_, Twox64Concat, Vec, (T::AccountId,T::BlockNumber)>; + + // (T::AccountId, u32,T::AccountId) + // T::AccountId, the anchor owner ss58 address + // u32, the sell price for the anchor + // T::AccountId, the target buyer. If the same as owner, it is free to buy. + pub(super) type SellList = StorageMap<_, Twox64Concat, Vec, (T::AccountId, u32,T::AccountId)>; + ``` + +### anchor.js + +- exposed methods. Three parts : basic substrate functions, anchor data I/O functions, anchor exchange functions. It has been used in the demo freeSaying, but no isolated yet. And exchange part need to code this time. +Anchor.js can help developer accessing Anchor network by this single JS. + + ```JS + /*******************************/ + /* substrate related functions */ + /*******************************/ + + //link to target substrate node + exports.link=function(endpoint,callback){ + /* return callback && callback(PolkadotJS.API) */ + }; + + //load encry file to get pair + exports.load=function(file,password,callback){ + /* return callback && callback(pair) */ + }; + + //subcribe the latest block + exports.subcribe=function(callback){ + /* return callback && callback(anchorDataList) */ + }; + + //check account balance + exports.balance=function(ss58Address,callback){ + /* return callback && callback(amount) */ + }, + + /***********************************/ + /* Anchor pallet related functions */ + /***********************************/ + + /* data part */ + //get the latest anchor data + exports.latest=function(anchor,callback){ + /* return callback && callback(formattedAnchorData) */ + }; + + //get the anchor data on special block. + exports.target=function(anchor,block,callback){ + /* return callback && callback(formattedAnchorData) */ + }; + + //get the list data of anchor. + exports.history=function(anchor,callback,limit){ + /* return callback && callback(listofAnchorsData) */ + }; + + //set target Anchor data. + exports.write=function(pair,anchor,raw,protocol,callback){ + /* return callback && callback(toChainProcessStatus) */ + }; + + /* market part */ + //set Anchor status to sell. + exports.sell=function(pair,anchor,cost,target,callback){ + /* return callback && callback(true/false) */ + }; + + //buy anchor on sell. + exports.buy=function(pair,anchor,callback){ + /* return callback && callback(true/false) */ + }; + + //revoke anchor from selling. + exports.unsell=function(pair,anchor,callback){ + /* return callback && callback(true/false) */ + }; + ``` + +### Overview + +- **Total Estimated Duration:** 1 month +- **Full-Time Equivalent (FTE):** 1 +- **Total Costs:** 6,000 USDT + +### Milestone 1 — Anchor pallet testing & documents, anchor.js full function + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 6,000 USDT + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / GPLv3 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing 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. On anchor.js, will supply demo to test. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. I am not so fimilar with Docker, that will take a bit long time. | +| 0e. | Anchor pallet | Will fix if neccessary. Mainly testing this time. | +| 0f. | anchor.js | A demo with all functions will be developed by React | + +## Future Plans + +- Anchor is the data storage part of EasyPolka, it is the most important component. Next, the whole EasyPolka will be open source. At present, it includes the following contents. + +| Order | Name | Demo | Github | introduction | +| -----: | ----------- | ------------- | ------------- | ------------- | +| 1 | Anchor | wss://dev.metanchor.net | [https://github.com/ff13dfly/Anchor](https://github.com/ff13dfly/Anchor) | Linked list on chian & Name service | +| 2 | Saying | [https://freesay.net](https://freesay.net) | Not yet | Plinth for cApp | +| 3 | cSaying | on block 2,220 | Not yet | FreeSaying cApp , pure JS app | +| 4 | vGateway | [https://android.im/vGateway/](https://android.im/vGateway/) | Not yet | Gateway access to vServices | +| 5 | vManager | [https://android.im/vManager/](https://android.im/vManager/) | Not yet | Management portal for vServices | +| 6 | vHistory | No domain, node.js app | Not yet |Anchor cache vService | +| 7 | vSaying | No domain, node.js app | Not yet] | FreeSaying comment vService | +| 8 | vMarket | No domain, node.js app | Not yet | Free charge vService | +| 9 | vMix | No domain, node.js app | Not yet | Front mixer vService | +| 10 | vSocial | No domain, node.js app | Not yet | Fav & tread vService | + +![easypolka.png](http://android.im/anchor/easypolka_not.png) + +- The functions above, you can test on the cApp [freeSaying](https://freesaying.net). +It is not very stable to access Github here, so the left codes are on my private git server. + +- The whole EasyPolka framework works properly, but still so many details to fix and neccesary function to add. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website. + +- Demo cApp [freeSaying](https://android.im/vManager/) is published now. The test network is available, you can access [wss:dev.metanchor.net](wss:dev.metanchor.net). + +- I have tried twice to apply the Gant Application but not accepted. + Anchor, a key-value storage system for substate. Now, it is extended, and applying again, :-) + SimPolk, simulator of Polkadot. diff --git a/applications/Apron_Network.md b/applications/Apron_Network.md index 5d2d1117c48..2efd571020b 100644 --- a/applications/Apron_Network.md +++ b/applications/Apron_Network.md @@ -1,10 +1,9 @@ -# Open Grant Proposal +# Apron Network -* **Project Name:** Apron Network * **Team Name:** Apron Labs * **Payment Address:** 15tV6rQSwNgWQ1Z5pim2yJmELLvWNm5D4V -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview @@ -18,27 +17,22 @@ Maybe you are still thinking that it sounds terrible but no one can prove it. Le **On Nov. 11th, 2020, the API services from infura.io are down, and the idea of Apron Network comes out.** -The Apron Network is built by the Apron Labs powered by Substrate. It provides a Cross-chain Decentralized Infrastructure Services Network that will be used by blockchain node runners, DApp developers, the public chain community, and DApp users. Every DApp developer can discover the proper service provider for a specific blockchain through the decentralized infrastructure market on the Apron Network. The Apron Network can be run as a parachain of Polkadot. +The Apron Network is built by the Apron Labs powered by Substrate. It provides a Cross-chain Decentralized Infrastructure Services Network that will be used by blockchain node runners, DApp developers, the public chain community, and DApp users. Every DApp developer can discover the proper service provider for a specific blockchain through the decentralized infrastructure market on the Apron Network. The Apron Network can be run as a parachain of Polkadot. With the Apron Network, the DApp developers can find their API endpoint, node runners can provide infrastructure services to get profit and all the infrastructure services will be decentralized on the two-layers infrastructure service network. The Apron Network will guaranty there is no infura.io accident anymore! - - #### Integration The Apron Network can be run as a parachain on Polkadot, or an independent chain. The Apron Network contains Apron Node and Apron Market. The Apron Node is built with Substrate 2.0 Framework, and the OCW (Off-chain worker) will be included for API manage records. Apron Market consists of Apron Market Contracts and Apron Market Front End. The contracts will be implemented with Ink!, and the front-end will be built with polkadot.js. - - #### Team Interest -Most of the team members are DApp developers who suffer from the lacking of Ethereum API Endpoint and tightly rely on infura.io since we are not able to set up our full node due to funds. As we have known, most of the DApp developers have the same embarrassing situation as us. After shocked by the accident of infura.io, we are willing to build a decentralized infrastructure service network, and we name it the Apron Network. +Most of the team members are DApp developers who suffer from the lacking of Ethereum API Endpoint and tightly rely on infura.io since we are not able to set up our full node due to funds. As we have known, most of the DApp developers have the same embarrassing situation as us. After shocked by the accident of infura.io, we are willing to build a decentralized infrastructure service network, and we name it the Apron Network. With Substrate 2.0 Framework, we are able to build a customized blockchain network easily, and we have the ability to integrate an API Gateway to manage blockchain API services in Apron Node. With the Apron Network, the blockchain node runners can provide Infrastructure service easily and get profit through this decentralized infrastructure services network. +### Project Details - -### Project Details #### Architecture The Apron Network consists of **Apron Node**, **Arpon Market Contracts**, **Decentralized API Market**, and the **Apron SDK**. @@ -50,42 +44,32 @@ The Apron Network consists of **Apron Node**, **Arpon Market Contracts**, **Dece * Decentralized API Market lists all the API services registered and available for developers from the data in smart contracts. DApp developers search the API services according to their needs and choose the one with the proper price. * The Apron SDK makes the use of Apron Network easier. DApp developers can integrate this SDK in their app to dynamic switch blockchain entry-point according to their needs. - - #### Substrate / Polkadot Integration -The Apron Network can be run as a para-chain of Polkadot, and also can be run as an independent chain apart from Polkadot. +The Apron Network can be run as a para-chain of Polkadot, and also can be run as an independent chain apart from Polkadot. The whole network is built on top of the Substate 2.0 Framework, and OCW (off-chain worker) is used to report API usage statistics on which the billing relies. All the contracts will be implemented with Ink!, and the front-end of Decentralized API Market will be on top of polkadot.js. - - #### Scenarios * Node Runners - - ![img](https://raw.githubusercontent.com/Apron2050/graphics/main/Apron%20Node.jpg) -The above figure shows the role of each component act from the view of the blockchain node owner. To simply the scenario, we take an example. The para-chain node is running at the beginning, the Apron Node shown above is set up by the owner by staking some **$ANT**, and the Apron Node is accessible on the internet. The owner can configure Apron Node with the RPC entry point of the para-chain node, API access frequency, API access fee, and other limitations. After everything is configured, the Apron Node will be able to call the RPC interface of para-chain, and DApps will call the API through the Apron Node. The Apron Node calculates the API usage statistics of each caller, then stores this data through OCW (off-chain worker) on the chain for further billing. - - +The above figure shows the role of each component act from the view of the blockchain node owner. To simply the scenario, we take an example. The para-chain node is running at the beginning, the Apron Node shown above is set up by the owner by staking some **$ANT**, and the Apron Node is accessible on the internet. The owner can configure Apron Node with the RPC entry point of the para-chain node, API access frequency, API access fee, and other limitations. After everything is configured, the Apron Node will be able to call the RPC interface of para-chain, and DApps will call the API through the Apron Node. The Apron Node calculates the API usage statistics of each caller, then stores this data through OCW (off-chain worker) on the chain for further billing. * DApp Developers - - ![img](https://raw.githubusercontent.com/Apron2050/graphics/main/Apron%20Usage.jpg) For DApp developers, there are two components that will be used. One is the Decentralized API Market, the other one is the Apron SDK. Firstly, DApp developers search the API services in the API service repositories ( which is part of the Decentralized API Market) on the webpage. After finding the proper API service, the DApp developer will generate an API access key with the help of Apron Market Contracts. Finally, the DApp developer develops the DApp with the API access key to use the related API services. Of course, the DApp developer should pay the fee of using the API services according to the fee addressed by the API service provider. - #### Interface Specification The function provided by the pallet to report API usage statistics data is reportAPIUsage. + ``` 1. reportAPIUsage @@ -94,11 +78,11 @@ The function provided by the pallet to report API usage statistics data is repor - return: the calls number ``` -### Ecosystem Fit +### Ecosystem Fit -Infura.io is the typical infrastructure services provider that is totally centralized. +Infura.io is the typical infrastructure services provider that is totally centralized. -The Apron Network provides exactly the same API services as infura.io but in a decentralized way, thanks to Substrate 2.0 Framework which let us only focused on the logic on top of blockchain rather than re-develop a new blockchain. In the future, the Apron Network will provide a decentralized infrastructure services network. +The Apron Network provides exactly the same API services as infura.io but in a decentralized way, thanks to Substrate 2.0 Framework which let us only focused on the logic on top of blockchain rather than re-develop a new blockchain. In the future, the Apron Network will provide a decentralized infrastructure services network. ## Team :busts_in_silhouette: @@ -108,51 +92,60 @@ The Apron Network provides exactly the same API services as infura.io but in a d * Junjun - Full-stack Developer ### Contact + - https://apron.network -### Legal Structure +### Legal Structure + No Legal Entity ### Team's experience -Toney - - Over 13 years of experiences in Software Development - - Software Engineer in MS - - Mobile Game Developer - - Blockchain Game Developer - - The Chief Tech Officier of the team which wins TRON Accelerator 2018 Game Rewards +Toney + +* Over 13 years of experiences in Software Development +* Software Engineer in MS +* Mobile Game Developer +* Blockchain Game Developer +* The Chief Tech Officier of the team which wins TRON Accelerator 2018 Game Rewards -Junjun - - Over 15 years of experiences in Software Development - - Former Senior Software Engineer in Lucent - - DApp Developer - - Full-stack Developer +Junjun + +* Over 15 years of experiences in Software Development +* Former Senior Software Engineer in Lucent +* DApp Developer +* Full-stack Developer ### Team Code Repos + * Apron Labs: https://github.com/apron-network ### Team LinkedIn Profiles + * [Toney](https://www.linkedin.com/in/yi-sui-297a9223/) -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: + ### Overview + * **Total Estimated Duration:** 3 months * **Full-time equivalent (FTE):** 4 * **Total Costs:** 0.73 BTC -### Milestone 1 Example — Implement Substrate Modules +### Milestone 1 Example — Implement Substrate Modules + * **Estimated Duration:** 3 months * **Full-time Equivalent (FTE):** 4 -* **Costs:** 0.73 BTC +* **Costs:** 0.73 BTC -In the first milestone, the features for the PoC will be implemented and tested by limited users. +In the first milestone, the features for the PoC will be implemented and tested by limited users. The following components will be included: * Apron Node * Apron Market Contracts -* Decentralized API Market / Front End -* Apron SDK +* Decentralized API Market / Front End +* Apron SDK | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -167,8 +160,6 @@ The following components will be included: | 6. | Article | We will write an article published on media channels. | | 7. | DAO | A Apron DAO will be created to handle the governance of the Decentralized API Market. | - - ## Future Plans Community Plan @@ -180,8 +171,6 @@ Community Plan * Bounty Program. * Publish articles on media channels to expose the Apron Network. - - Development Plan * The Apron Network will run as a parachain of the Kusama. @@ -191,9 +180,7 @@ Development Plan * In phase 3, provide decentralized quick node services. * Finally, our goal is to provide the infrastructure services network. - - -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: Currently we just start the first design of the Apron Network. diff --git a/applications/ArtZero_InkWhale.md b/applications/ArtZero_InkWhale.md new file mode 100644 index 00000000000..7bcd22fc528 --- /dev/null +++ b/applications/ArtZero_InkWhale.md @@ -0,0 +1,141 @@ +# ArtZero & InkWhale + +- **Team Name:** ArtZero +- **Payment Address:** 1scixS3ofLuBN8XEQQdSjMQaLtvvbcJiQAqpnaov8xopX78 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +The ArtZero is a decentralized NFT marketplace on the Aleph Zero blockchain. It is the first NFT marketplace on Aleph Zero, allows everyone to Create, Buy, Bid, Sell, or just Collect Aleph Zero-based NFTs. The platform comes with its native Praying Mantis Predators NFT Collection, which NFT owners can stake for share of platform profit and other perks. ArtZero also provides a launchpad to let anyone to launch their NFT Collection. + +Ink Whale lets stakers earn fixed interest and other rewards for locking up your tokens or NFTs. Unlike traditional yield farming, where you need to deposit tokens into a liquidity pool to get token rewards, NFT farming uses NFTs instead. The main goal of NFT farming is to create liquidity and utility for NFTs. + +The Smart Contracts of ArtZero and Ink Whale use Ink! Substrate are currently working on Aleph Zero but the Smart Contracts can be deployed on any parachains that support Ink! + +### Overview + +### Project Details + +Our Project, ArtZero is in Smart Contract Audit by BrushFam, the team behinds OpenBrush Library. We will be ready to launch on Aleph Zero network once Ink! 4.0 is deployed on the chain. Demo Testnet Version of the project can be accessed at https://artzero.io + +Ink Whale is still in development and the MVP is completed for public test at https://inkwhale.net + +### Ecosystem Fit + +SubWallet is our friend and partner, their office is literally 5 minutes from our office and we have collaborated on many things in the past. Our team helped SubWallet in the development of https://dotinsights.subwallet.app/ and also working with SubWallet to integrate Aleph Zero blockchain to their wallet. + +Ink Smart Contract is very new, but our team has strong knowledge of development on Ink!. ArtZero is also one of the very first dapps developed on Ink Ecosystem. + +In Nov 2022, we also received the bounty for find a serious bug in Substrate Ink! by Parity Security Team. The fix is at PR #11771. + +We believe that with our strong interest in Ink!, we can provide a lot of benefits to the ecosystem such as development training and supporting. + +## Team :busts_in_silhouette: + +### Team members + +Mr. Brian Nguyen (founder, engineer) +There are another 4 key members in the company including: +Mrs. Phuong Hoang - CMO +Mr. Frankie Kao - Art Director and team of 5 designers +Mr. Long Nguyen - Full-stack developer +Mr. Albert Tran - Smart Contract & Back-end Developer +Mr. Tuan Vu - DevOp +Mr. Thien Nguyen - Front-end Developer +Mr. Nam Hoang - Blockchain Developer +Mr. Tung Nguyen - Back-end and Blockchain Developer + +Other part-time testers and designers. + +### Contact + +- **Contact Name:** Brian Nguyen +- **Contact Email:** admin@artzero.io +- **Website:** https://artzero.io + +### Legal Structure + +- **Registered Address:** Not Registered +- **Registered Legal Entity:** Not Registered + +### Team's experience + +Brian Nguyen graduated from University of Nottingham with a 1st class degree in Computer and Electronics Engineering. Over the last 15 years, He has developed many data-driven applications. He also has deep interest in blockchain technology and development of decentralized apps on Ethereum, Binance Smart Chain, Tron, Solana +network. He is the founder of ArtZero - the first NFT Marketplace & also 1st dApp on Aleph Zero network. + +Frankie Kao owns a design company and have been working in many projects on web design, graphic designs etc. He dedicated his resources to work with ArtZero. + +Phuong Hoang has been in sale and marketing industry for over a decade. She has been Sale and Marketing Manager/Director for many companies including: Honda Vietnam, Plex Cinama, Saga Media etc. + +All of our developers have at least 5-10 years experience in software development. + +### Team Code Repos + +- https://github.com/artzero-io (some repos are in private mode) + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/nad128668/ +- http://linkedin.com/in/phuong-phoebe-hoang-4b5888148 +- https://www.linkedin.com/in/tran-albert-469b6319a + +## Development Status :open_book: + +We have completed the Testnet demo version of the ArtZero NFT Marketplace. The first version of the contracts are waiting to be audited then our platform will be ready to be launch on Aleph Zero Mainnet. + +https://artzero.io +https://docs.artzero.io/ + +Ink Whale is still in development and the MVP is completed for public test at https://inkwhale.net + +## Development Roadmap :nut_and_bolt: + + +### Overview + +- **Total Estimated Duration:** 4 months +- **Full-Time Equivalent (FTE):** 5 FTE +- **Total Costs:** 30,000 USD + + +### Milestone 1 — NFT Marketplace on Polkadot Parachains +* **Estimated Duration:** 8 weeks +* **Costs:** 15,000 USD + +In this milestone, We will create Smart contracts to be compatible with Ink!4.0 Polkadot Parachains with full working NFT Marketplace UI/UX and backend. + +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| 0a. | License | Apache License 2.0 | +| 0b. | Documentation | We will provide technical documents and user guides | +| 0c. | Testing Guide | We will provide Test Plan and Test Results for operating and using the NFT Marketplace | +| 0d. | Article/Tutorial | We will write an article or tutorial that explains the NFT Marketplace | +| 1. | Smart contract Development | We use ink! to develop the contracts and the functions that contracts support are: list, unlist NFT, buy NFT at fixed price, bid for an NFT, accept an NFT bid, add NFT Collection, add a launchpad project. We need to develop the contracts using project structure as defined in https://github.com/Supercolony-net/openbrush-contracts/tree/main/example_project_structure to meet higher code standard for better code management. The functions are partly built with psp34 support and still need more work to be compatible with psp37 (erc1155) standard. | +| 2. | Backend | Build infrastructure to serve the need of NFT Marketplaces. We use nodejs and mongodb on AWS Services. The backend will have an api service that serves the front end and cron jobs to fetch data from blockchains to save into the local database. The API definition can be found at https://docs.google.com/document/d/1bPq9aFMaaVgKgsYWG3K4APubRK33OloY4_gHM3c8wo0/edit and it needs development to work on all Polkadot's parachains. The backend will have to handle the following tasks: Monitor NFT bids in the queue and update Bid table in the database; Cache Images from IPFS to CloudFlare Image; Cache NFT Metadata to local database; Monitor NFT Collection changes and update the database; Monitor NFT Information and update the database; Telegram bot to alert system operators: queue length and access attempt and work load. | +| 3. | Frontend | Create new front-end for the NFT Marketplace, we have 2 mockups at https://www.figma.com/file/76ER4HZUR1KMDaxctx5BS6/DragonSUI?node-id=146%3A68 and https://www.figma.com/file/xsVkm8VOdTqyPWPgTrbQpl/ArtZero?node-id=275%3A12 these are under converting from Figma to ReactJS code. | +| 4. | Testing | We will provide unit test for smart contracts. For Frontend and Backend testing we will provide Test Document with Plan and Test Cases for operating and using the NFT Marketplace | + +### Milestone 2 — Ink Whale Staking and Yield Farming Platform Development +* **Estimated Duration:** 8 weeks +* **Costs:** 15,000 USD + +In this milestone, We will continue to improve the current development of Ink Whale Platform to completion. + +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| 0a. | License | Apache License 2.0 | +| 0b. | Documentation | We will provide technical documents and user guides | +| 0c. | Testing Guide | We will provide Test Plan and Test Results for operating and using the staking and yield farming platform. | +| 0d. | Article/Tutorial | We will write an article or tutorial that explains the work principle as part of the grant. | +| 1. | Smart Contract Development | Enhance the current smart contracts in MVP. The contracts will be compatible with Ink!4.0 and have following functions: create PSP22 token, create a staking pool, create NFT yield farm, create token yield farm, add rewards to pool, remove rewards from pool, claim reward from pool. We have to create 9 different contracts; WAL token contract that allows public minting and fixed total supply; General psp22 token contract and psp22 token generator contract; Pool Contract and Pool Generator Contract; NFT Farming Contract and NFT Farming Generator Contract; LP Farming Contract and LP Farming Generator Contract. | +| 2. | Backend | Build infrastructure to serve the need of Ink Whale. We use nodejs and mongodb on AWS Services. The cronjob monitor update queue to make sure data in the database match with data on-chain; The API serves the frontend with following functions: getTokens, getPools, getLPPools, getNFTPools, getPoolsbyOwner and getPoolsbyAddress. update API also required to add update request to the database queue and serves the cronjobs. | +| 3. | Frontend | Revamp the front-end for final version, better UI/UX. The new design is currently in progress and can be found at https://www.figma.com/file/63xCCH71Oa8AfJpkK1wCO3/Ink-Whale?node-id=88%3A234. The current demo can be seen at https://testnet.inkwhale.net | +| 4. | Testing | We will provide unit test for smart contracts. For Frontend and Backend testing we will provide Test Document with Plan and Test Cases for operating and using Ink Whale platform | + + +## Future Plans + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** from Founder of SubWallet diff --git a/applications/Awesome-Polka.md b/applications/Awesome-Polka.md new file mode 100644 index 00000000000..aa330f8f80e --- /dev/null +++ b/applications/Awesome-Polka.md @@ -0,0 +1,247 @@ +# Awesome Polka + +- **Team Name:** Awesome Polka +- **Payment Address:** [0xa632439DE1592936fbA3368053eaafd491443493](https://etherscan.io/address/0xa632439DE1592936fbA3368053eaafd491443493) (USDC, Ethereum (ERC20)) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + +### Overview + +Awesome Polka - the ultimate social platform for discovering and exploring the most exciting projects in the Polkadot ecosystem! Whether you're a developer, investor, or simply a curious enthusiast, Awesome Polka provides a one-stop-shop for accessing comprehensive and detailed applications about the projects. With this cutting-edge platform, you can discover the latest updates and developments, connect with project owners, and stay up-to-date with the most innovative projects in the Polkadot community. + +### Project Details + +Project showcase platforms face several challenges that hinder their effectiveness in promoting and highlighting various projects. The most significant challenges include sustainability and limited ecosystem partner (admins - authorized ones like someone from a DAO) authorities on the platform. These challenges significantly affect user experience and discourage project owners and ecosystem partners from utilizing the platforms fully. To address these issues, there is a need to develop innovative and user-centric strategies that enhance the functionality and sustainability of showcase platforms. + +General overview of Awesome Polka: + +![Awesome_Polka_Mindmap](https://user-images.githubusercontent.com/40897846/223079422-f5d8a6bc-da20-4be8-a0a9-2f1f84f15795.png) + +### Problems + +Let's take a closer look at some of the issues of project showcase platforms that I have encountered: + +**Sustainability**: The long-term sustainability of a platform depends on its ability to consistently deliver value to its users. Manual updates to listed projects through forms and limited content control can result in outdated or inaccurate information, reducing user trust and engagement. + +**UI & UX**: The user experience (UX) of a website or platform can significantly impact user engagement and satisfaction. Poorly designed UIs, slow loading times, confusing navigation, and other factors can all contribute to a low UX, hence reducing user engagement. + +**Poor Search Algorithms**: A platform showcasing tens of projects will require an effective search algorithm to help users easily find the specific project they are looking for. Weak search algorithms can result in irrelevant search results, leading to frustration and decreased user engagement. + +**Static Project Pages**: A project page should provide detailed information about the project, such as its objectives, methodology, team members, progress, and impact. A page that only includes a brief description can leave users with unanswered questions and reduce their interest in the project. + +**Educational Materials & Articles**: For users interested in a particular project, educational materials and related articles can provide valuable context and additional information. Making these resources easy to find and linking them directly to the relevant project pages can enhance user engagement and interest. + +**Ecosystem Partner Rights**: Partnerships with DAOs or other ecosystem partners can bring significant benefits to a platform, such as increased visibility, funding, and community support. However, without proper rights and access, these partners may not be able to fully leverage their resources and expertise to help the platform grow and succeed. + +### Solutions + +Awesome Polka is a social platform that aims to benefit the broader Polkadot developer ecosystem in several ways. Firstly, as Polkadot is one of the fastest-growing protocols, having a platform like Awesome Polka that aggregates all the projects in the ecosystem can help to further increase its size and diversity. + +Additionally, Awesome Polka provides a fluent user experience that enables more people to stay informed about what's happening on Polkadot. By making it easy to access detailed information about projects and events, Awesome Polka helps to promote collaboration and engagement among developers and enthusiasts alike. + +Finally, the platform will be continually supported through Twitter sharing and events, ensuring that it remains a vibrant hub of activity within the Polkadot ecosystem. + +Awesome Polka provides solutions to the problems mentioned in the previous statements in the following ways: + +**Solution to Sustainability** + +Awesome Polka has 2 personas for managing the platform: **Project owners** that want to publish their project on Awesome Polka, and **ecosystem partners** that is authorized ones like someone from a DAO, or from Polkadot team. + +Project owners can send a request to publish their project. After review and approval, they will receive login information to publish and edit their project's page via their web3 wallets on a special dashboard. This enables project pages to be updated by project owners all the time and have unique dynamic pages. + +On the other side, ecosystem partners can have admin access to Awesome Polka. They can approve or reject projects and request to remove any harmful content with an explanation. This allows ecosystem partners to help manage Awesome Polka and ensure that all projects are aligned with sustainability goals. + +In summary, Awesome Polka provides a platform where project owners and ecosystem partners can work together to create long-term sustainable platform. By empowering project owners to create and manage their own projects and providing ecosystem partners with the tools to manage and monitor the platform, Awesome Polka helps to create a sustainable future for all. + +**Improvement on UI & UX** + +Awesome Polka has a simple and effective user interface that makes it easy to navigate the website and find the information you are looking for. With just a few clicks, users can access general information and project details on the platform. The user interface has been designed to be fresh and cross-platform compatible, which ensures a seamless and enjoyable user experience regardless of the device or browser used. + +The platform is continually undergoing UI developments to enhance the user experience further. At the final stage of development, the user interface will be fully responsible and optimized for all screen sizes, ensuring that users have a consistent and enjoyable experience across all devices. Overall, Awesome Polka prioritizes usability and user experience to create a platform that is both informative and easy to use. + +Home Page | Projects Page | Articles Page +:-------------------------:|:-------------------------:| :-------------------------: +![Awesome Polka Home Page](https://user-images.githubusercontent.com/40897846/223079619-cd90d6e0-f406-4d0f-bfda-00126b4d41d5.png)| ![Awesome Polka Projects Page](https://user-images.githubusercontent.com/40897846/223079640-0e47ab39-b667-4819-a20f-f1257449bf5c.png) | ![Awesome Polka Articles Page](https://user-images.githubusercontent.com/40897846/223079652-157a8c4e-a28f-40ea-9aa4-feadc5386e8d.png) + +**Solution to Poor Search Algorithms** + + +Awesome Polka has a powerful search infrastructure that uses Algolia to deliver detailed and lightning-fast search results. + +On Awesome Polka, category list exist to organize projects in detail. Ecosystem partners can add categories to this category list according to ecosystem needs, while project owners can select their category and subcategory while adding their project to the platform. Awesome Polka automatically integrates new categories into relevant pages to increase search efficiency. + +Moreover, Awesome Polka's search infrastructure uses a detailed searching matrix. Unlike most showcase platforms that only use titles to search for anything, Awesome Polka's range of parameters is much wider, ranging from titles to project descriptions. This ensures that users can find what they are looking for more easily and with greater precision. + +In summary, Awesome Polka's search infrastructure is designed to provide a seamless and efficient user experience. Additionally, ecosystem partners work to ensure that the platform's categories are up-to-date and relevant to the needs of the community, further enhancing the search experience. + +Search Element | Search Focused +:-------------------------: | :-------------------------: +| + +**Solution on Static Project Pages** + +On Awesome Polka, project owners can manage their project pages, which include several modules such as: + +- Project Description +- Token Stats +- GitHub Stats +- Team Info +- Latest Articles +- Frequently Asked Questions +- Job Postings + +The number of these modules will be increased and further developed. + +Project owners can update their project page using these modules. In the future, additional modules can be added based on the needs of the ecosystem. + +In summary, project pages on Awesome Polka are highly customizable, allowing project owners to showcase their projects using a variety of modules. By providing these modules, Awesome Polka enables project owners to provide up-to-date information about their projects and engage with the ecosystem more effectively. + +**Improvement on Educational Materials & Articles** + +Awesome Polka offers a platform for project owners to publish educational materials and articles to inform and engage with the ecosystem. With the built-in editor, project owners can create compelling content that keeps their audience up-to-date on the latest developments in their projects. By providing these tools, Awesome Polka helps to create a more informed and engaged community. + +**Improvement on Ecosystem Partner Rights** + +Ecosystem partners play a crucial role in ensuring the sustainability of the Awesome Polka platform. By giving them admin rights, they can help manage the platform and ensure that it meets the needs of the community. The committee responsible for this role will be selected based on their ability to review and manage projects effectively. + +#### Technology Stack + +- AWS App Sync (GraphQL) +- AWS Amplify +- Next.js +- Additional Tools & Frameworks + - Redux + - Tailwind CSS + - Magic (Web3 Auth & Wallet) + - Algolia (Search Infrastructure) + +#### Documentation + +Once all project milestones have been accomplished, we will create and publish comprehensive technical documentation that provides all the necessary information for end users to fully understand the system and its capabilities. + +#### PoC/MVP or other relevant prior work or research on the topic + +**Awesome Polka MVP Link:** https://dev.awesomepolka.org + +### Ecosystem Fit + +- **Where and how does your project fit into the ecosystem?** + + Polkadot's [User Interface section](https://wiki.polkadot.network/docs/build-open-source#user-interface) is the ideal place to start for the Awesome Polka project, offering the best opportunity for success. + +- **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** + + Awesome Polka targets a diverse range of audiences, including individuals who are interested in learning about Polkadot projects and their latest updates. This includes investors, enthusiasts, and other stakeholders who want to stay up-to-date with the developments in the Polkadot ecosystem. + + In addition to individuals, Awesome Polka also targets both early-stage and live projects on the Polkadot ecosystem. By providing a comprehensive platform that supports projects of all sizes, Awesome Polka aims to support the growth and development of the entire Polkadot ecosystem. + + Furthermore, Awesome Polka also targets ecosystem partners such as DAOs who can help to make the platform more sustainable and aligned with their vision. By engaging with the community and involving ecosystem partners in the management of the platform, Awesome Polka aims to create a more collaborative and impactful platform that benefits everyone involved in the Polkadot ecosystem. + +- **What need(s) does your project meet?** + + Awesome Polka meets the needs I mentioned in the solution section above, but if I have to write it as a summary, it covers the following: + + - **Sustainable project management:** The project ensures sustainable project management by providing a comprehensive and structured approach to project management. This approach includes planning, execution, monitoring, and control of project activities, which helps to achieve project goals while minimizing risks and resource wastage. + + - **Strong SEO optimization:** The project meets the need for strong SEO optimization by implementing best practices for on-page and off-page SEO. This includes optimizing content for keywords, ensuring site speed and mobile responsiveness, and building high-quality backlinks to improve search engine rankings and visibility. + + - **Fresh and easy-to-use UI:** The project meets the need for a fresh and easy-to-use UI by providing a user-friendly interface that is intuitive and easy to navigate. This helps to enhance the user experience and encourages users to engage with the project more frequently. + + - **Efficient and lightning-fast search infrastructure:** The project meets the need for efficient and lightning-fast search infrastructure by implementing a robust search system that enables users to find the information they need quickly and easily. This ensures that users can access the project's content and resources without delays, which improves overall usability and satisfaction. + + - **Detailed project modules:** The project meets the need for detailed project modules by providing comprehensive information on various project aspects such as token stats, GitHub activity, job postings, and so on. This helps users to stay informed about project updates and developments, which enhances transparency and trust in the project. + +- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** + - **If so, how is your project different?** + - Yes, I found a similar project called Polka Project, there may be other projects, but let me tell you about the differentiating aspects of Awesome Polka. + - Detailed filtering and search options for easier and efficient project discovery + - Ability for projects to use modules for article sharing and job postings and so on + - Display of GitHub repository information and statistics + - Display of token information, including market capitalization, total volume, and price + - A learning section with resources for the Polkadot ecosystem + - Sharing of project team information. + - Dashboard for Projects Owners and Admins to manage platform sustainable. + +## Team :busts_in_silhouette: + +### Team members + +- Tolga Yaycı + +### Contact + +- **Contact Name:** Tolga Yaycı +- **Contact Email:** [tolgayayci@protonmail.com](mailto:tolgayayci@protonmail.com) +- **Website:** [LinkedIn](https://www.linkedin.com/in/tolgayayci/) + +### Legal Structure + +- **Registered Address:** - +- **Registered Legal Entity:** - + +### Team's experience + +As a full-stack developer with 2 years of experience, I have honed my skills in software development, with a focus on dApp development in the past year. I have a deep interest in the Web3 and NFT space and have put my skills to the test by creating a number of relevant applications. In addition to my experience, I have developed detailed React and Next.js projects, further enhancing my ability to build robust and scalable web applications. + +In addition to my technical skills, I have also been actively involved in the wider tech community. I have served as a Chainlink Community Advocate, Aave Turkey Community Manager, and Founding Chair of Gazi University ACM Student Chapter. My previous role as a Microsoft Learn Student Ambassador has also given me the opportunity to share my knowledge and experience with others. I have set of experiences and skills and particularly in the areas of full stack software development and community management. + +### Team Code Repos + +- https://github.com/tolgayayci/awesome-polka/tree/dev +- https://github.com/tolgayayci + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/tolgayayci + + +## Development Status :open_book: + +The user interface and search infrastructure of this project are largely complete and ready for discovery. To get a glimpse of the minimum viable product (MVP), you can either take a look at the repository or visit the website. + + + +## Development Roadmap :nut_and_bolt: + +This project is planned as 1 milestone, it will be completed in one months. + +- **Total Estimated Duration:** ~1 month +- **Full-Time Equivalent (FTE):** 1 +- **Total Costs:** 10,000 USD + +### Milestone 1 + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Unlicense | +| **0b.** | Documentation | I will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | I will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| **0e.** | Article | I will publish an **article**/workshop that explains what was done/achieved as part of the grant. | +| **1.** | UI & UX Development | **Home Page:** Visually appealing and user-friendly homepage which includes latest articles, popular categories and many more
**Projects Page:** Showcase page with detailed filtering and search infrastructure
**Project Detail Page:** Project details page to display detailed information about project with several modules like explained in the solution
**Articles Page:** Articles page to showcase informative articles related to the subject
**Article Detail Page:** Detail page for individual articles to display their full content
**Ranking Page:** Ranking page based on votes and token stats which is supported by CoinGecko api to showcase popular projects and articles
**Learn Page:** Useful resources to learn about polkadot ecosystem
**UX Improvements & Testing:** I will work to improve the user experience by ensuring that the user interface is fully compatible with mobile and tablet devices. | +| *2.* | Project Owner Dashboard | As part of this milestone, I will be implementing both the frontend and backend components of the Project Owner Dashboard. This involves designing and developing the user interface (UI) for the dashboard, as well as building the necessary backend infrastructure to support its functionality. To ensure the quality of my work, I will conduct thorough testing to ensure that the dashboard is user-friendly and performs as expected. My ultimate goal is to provide project owners with a seamless and efficient experience when updating their pages and publishing articles on our platform. + +## Future Plans + +I will manage the **@awesomepolka** Twitter account and keep the followers of the Awesome Polka community updated on the latest projects added to the platform. Additionally, I will create monthly threads to share developments with the community. + +Besides, to ensure the best possible user experience, I will actively monitor the Awesome Polka platform for any bugs or technical issues that may arise. I am committed to maintaining the platform's quality, and any problems that are identified will be addressed promptly. + +I will conduct ongoing maintenance and support for a year to ensure the smooth functioning of the platform. If users encounter any issues while using Awesome Polka, they can report them by creating a GitHub issue or by filling out a form that is available on the website. + + My goal is to provide a reliable and user-friendly platform for the web3 community, and I am dedicated to addressing any issues that arise in a timely and efficient manner. + +## Referral Program (optional) :moneybag: + +- **Referrer:** - +- **Payment Address:** - + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website + diff --git a/applications/BCANN.md b/applications/BCANN.md index ce2af128727..b828a71a40b 100644 --- a/applications/BCANN.md +++ b/applications/BCANN.md @@ -1,28 +1,27 @@ -# W3F Open Grant Proposal +# BCANN ( The blockchain system for Assigned Names And Numbers ) > 🌏 This page is also available in [Chinese (中文)](./application-template-cn.md). -> +> > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. -> +> > See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/#pencil-process) on how to submit a proposal. -* **Project Name:** BCANN ( The blockchain system for Assigned Names And Numbers ) * **Proposer:** Witter Lee * **Payment Address:** 0x4575f459F79B6ed5Dd644aBCc64affCc4c680DE3 * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/353#issuecomment-946463960) - -## Project Overview : +## Project Overview ### Overview + BCANN is a protocol of assigned names & numbers & crypto-currency addresses for multi-chain. ### Background + DNS is the infrastructure of the Internet,an efficient resource addressing method. But DNS has some common problems like below - 1.Domain name hijacking 2.DNS cache pollution 3.DDOS attack @@ -34,21 +33,20 @@ 2.Prevent DNS cache pollution by distributed ledger for Name Services 3.DDOS can not attack all decentralized name service nodes - There are some decentralized DNS projects, such as Namecoin, ENS, etc. These projects solve many central service problems, but the boundary of the blockchain makes DNS unable to act on the blockchain outside of itself. The Polkadot cross-chain ecosystem breaks the boundaries between the blockchain and makes it possible for the deentralized DNS, and that's why we created this project. -### Project Details +### Project Details [architecture](https://drive.google.com/file/d/1eD3fqQ0p7osblX1x-iW3hPLhIWG3R4Lv/view?usp=sharing) The BCANN protocol will allow parachains to quickly obtain the complete functions of decentralized domain names through the Polkadot parachain module, and meet the needs of developers on the parachain for the name services's functions. - #### Interface Specification Main interface (Users can implement the Resolver by themselves for extension) + ``` 1. name registry /** @@ -156,7 +154,7 @@ Main interface (Users can implement the Resolver by themselves for extension) ``` -### Ecosystem Fit +### Ecosystem Fit There is a [deeper.network](https://github.com/w3f/Open-Grants-Program/blob/master/applications/deeper_network.md) project that includes decentralized DNS. There are several diferences worth highligting: @@ -164,13 +162,11 @@ There is a [deeper.network](https://github.com/w3f/Open-Grants-Program/blob/mast There is a [ens](https://ens.domains/) project. There are several diferences worth highligting: -*ENS is a smart contract deployed on ETH,BCANNN is the infrastructure of the parachain, which will be released as a substrate runtime module library. - +*ENS is a smart contract deployed on ETH,BCANNN is the infrastructure of the parachain, which will be released as a substrate runtime module library. There is a [Nicks Module](https://github.com/paritytech/substrate) project. There are several diferences worth highligting: *Nicks Module is a module that keep track of account names on-chain.BCANN provides a complete domain name service and address mapping service. - There is a [substrate-names](https://github.com/xaya/substrate-names/) project. There are several diferences worth highligting: @@ -180,11 +176,10 @@ There is a [substrate-name-service](https://github.com/hskang9/substrate-name-se *Support of Substrate-name-service for subdomains is not good enough, and only supports IPV4. This is just a sample project and the updating has been stopped. BCANN provides complete domain name/subdomain name service and address mapping service. -Name services is an infrastructure for blockchain ecosystem. In the blockchain world, the human-readable name is the effective identification for hash, addresses, and other items, which improves the usability. +Name services is an infrastructure for blockchain ecosystem. In the blockchain world, the human-readable name is the effective identification for hash, addresses, and other items, which improves the usability. Usage scenarios: - a. Human-readable identity for decentralized social media b. Human-readable identity for decentralized email c. Human-readable identity for the address to send asset @@ -193,57 +188,63 @@ Usage scenarios: BCANNN will create a name service protocol on polkadot parachain. As a basic protocol of the name service, BCANNN will have built-in support for name/subname registry and resolver,and it shall support existing blockchain domain names, such as .eth, .luxe, etc., through adapter contract. That means users can use BCANNN as a common resolver for all blockchain domain to query/update name services records. - ## Team :busts_in_silhouette: ### Team members + * Witter Lee * Chak Zhou * Andy An ### Contact + * **Contact Name:** Witter Lee * **Contact Email:** lwt@msn.cn -### Legal Structure +### Legal Structure + - No.2588 Hongmei South Road, Minhang District, Shanghai -- Shanghai Blockchain Network Technology Co., Ltd. +* Shanghai Blockchain Network Technology Co., Ltd. ### Team's experience + Witter Lee : Full stack engineer with 12+ years of experience 7 years of experience in the blockchain industry - 4 years of experience in smart contract + 4 years of experience in smart contract 2013~2014 RippleChina.cn's CTO 2014~2016 fullcoin.com exchange's CTO 2016~2018 19800.com exchange CEO & CTO - 2018~2020 azex exchange CEO + 2018~2020 azex exchange CEO Chak Zhou : Full stack engineer with 10+ years experience 4 years of experience in the blockchain industry - 2 years of experience in smart contract development + 2 years of experience in smart contract development 2010~2014 Senior engineer of Travel e-commerce 2014~2016 Senior engineer of cross-border e-commerce 2017~2018 19800.com exchange CTO - 2018~2020 azex exchange CTO + 2018~2020 azex exchange CTO Andy An : Senior engineer engineer with 10 + years experience 2 years of experience in the blockchain industry - 2 years of experience in smart contract + 2 years of experience in smart contract 2010~2016 Senior engineer of alipay 2016~2018 Senior engineer of 19800.com exchange 2018~2020 Senior engineer of azex exchange We come from a long-term cooperation team, we have 5+ years experience in blockchain industry, like blockchain technology , smart contract development, We have 2+ years of experience in researching on the ens project. -## Development Roadmap +## Development Roadmap + ### Overview + * **Total Estimated Duration:** 12 weeks * **Total Costs:** 10,000.00 DAI ### Milestone 1: Initial implementation, name service registry and name resolver + * **Estimated Duration:** 4 weeks * **Full-time equivalent (FTE):** 2 * **Costs:** 5,000 DAI @@ -252,7 +253,7 @@ We come from a long-term cooperation team, we have 5+ years experience in blockc | ------------- | ------------- | ------------- | | 0a. | License | MIT | | 0b. | Documentation | We will provide inline documentation of the code and basic tutorials, which will explain how to use name services| -| 0c. | Testing coverage | The code will have unit-test coverage (min. 90%) to ensure functionality and robustness. We will describe how to run these tests in the guide.| +| 0c. | Testing coverage | The code will have unit-test coverage (min. 90%) to ensure functionality and robustness. We will describe how to run these tests in the guide.| | 1. | Module design| The name/sub-name will enable NFT support for names transfer/rental services | | 2. | Customizable Resolver | We will implement methods to set up custom resolver| @@ -261,9 +262,10 @@ a. Official website with project introduction b. ParaChain frame source code, protocol introduction document and module deployment document c. Unit testing and test documentation +### Milestone 2: Example of name services dapp -### Milestone 2: Example of name services dapp [mock-ups for milestone 2](https://org.modao.cc/app/4447109c463ec3a36043cb54e1edd7fafcc01c2c?simulator_type=device&sticky) + * **Estimated Duration:** 4 weeks * **Full-time equivalent (FTE):** 3 * **Costs:** 5,000 DAI @@ -273,13 +275,13 @@ c. Unit testing and test documentation | 0a. | License | Apache 2.0 | | 0b. | Documentation |We will provide documentation on how to get a name/subname, and how to use your name/subname for crypto address resolve | | 0c. | Testing Guide | We will provide users with a test name services, and users can get a 30-day test period for a name/subname | -| 1. | ns dapp| We will implement a dapp to get/manage/transfer your name/subname. +| 1. | ns dapp| We will implement a dapp to get/manage/transfer your name/subname. We will implement a dapp at this milestone. The deliverable part includes: a. Dapp for getting/managing/transferring your name/subname b. Dapp for getting/managing/transferring your name/subname for test purpose (free name/subname) ## Future Plans - - 1. We will create a mail system for name/subname which offers common mail service with crypto currency sending service + + 1. We will create a mail system for name/subname which offers common mail service with crypto currency sending service 2. We will create a BCANN parachain for each parachain as the superset of the registry data, it can provide developers with one-stop domain name registry and resolve services diff --git a/applications/BandersnatchVRF.md b/applications/BandersnatchVRF.md new file mode 100644 index 00000000000..3abeb527a21 --- /dev/null +++ b/applications/BandersnatchVRF.md @@ -0,0 +1,352 @@ +# TypeScript Bandersnatch VRF Suite – Complete Cryptographic Implementation for JAM Protocol + +- **Team Name:** Esscrypt Ltd. +- **Payment Details:** +- **DOT**: 15JRT5GjLAZkuvmpwmjCUp1RRLr7Y6Gnusz37ia37h2Xn5Rz +- **Payment**: 15JRT5GjLAZkuvmpwmjCUp1RRLr7Y6Gnusz37ia37h2Xn5Rz (USDC) +- **Level:** 2 + +## Project Overview :page_facing_up: + +### Overview + +The JAM protocol represents the next generation of blockchain consensus, requiring robust cryptographic primitives for secure randomness generation, validator selection, and privacy-preserving operations. While the reference implementation exists in Rust via [`ark-vrf`](https://crates.io/crates/ark-vrf) , **security best practices mandate independent implementations** to enable cross-verification and eliminate single points of failure. + +Our TypeScript implementation delivers **enterprise-grade cryptographic security** with **superior developer experience** and **broader ecosystem compatibility** , maintaining full compliance with Web3 Foundation specifications and IETF standards. + +This comprehensive suite provides **complete VRF functionality** including IETF-compliant VRF, Pedersen VRF, Ring VRF, and Elligator2. Our implementation enables seamless integration with modern web applications, browser-based clients, and Node.js environments—critical for the decentralized future. + +**Key Advantages:** +- **Zero Rust Dependencies**: Pure TypeScript implementation eliminates compilation complexity +- **Browser-Ready**: Direct integration with web applications and browser-based wallets +- **NPM Ecosystem**: Seamless integration with existing JavaScript/TypeScript projects +- **Cross-Platform**: Universal compatibility across Node.js, browsers, and edge environments +- **Developer-Friendly**: Comprehensive TypeScript types and intuitive APIs + + +#### Relation to JAM Protocol + +The [Bandersnatch VRF](https://github.com/davxy/bandersnatch-vrf-spec) specification developed under Web3 Foundation are **critical components** of the JAM protocol's consensus mechanism. Our TypeScript implementation provides: + +- **Enhanced Security Through Diversity**: Multiple independent implementations enable cross-verification and prevent single points of failure +- **Broader Ecosystem Access**: Extends JAM's cryptographic primitives beyond Rust to the entire JavaScript/TypeScript ecosystem +- **Developer Adoption**: Enables web developers, browser-based applications, and Node.js services to participate in JAM networks +- **Research Innovation**: Provides additional implementation perspectives for cryptographic research and protocol improvements + +#### Why Our Implementation Matters + +As active contributors to the JAM ecosystem through our **PeanutButterAndJAM** implementation, we identified a critical gap: **overwhelming dependency on Rust-based cryptographic libraries** creates barriers for developers and limits ecosystem diversity. Our TypeScript implementation addresses this by: + +- **Eliminating Language Barriers**: Enables JavaScript/TypeScript developers to build JAM-compatible applications without Rust expertise +- **Browser Integration**: Provides cryptographic primitives directly accessible in web browsers for client-side applications +- **NPM Distribution**: Makes JAM cryptographic tools available through the world's largest package registry +- **Cross-Platform Compatibility**: Ensures consistent cryptographic behavior across Node.js, browsers, and edge computing environments +- **Developer Experience**: Offers comprehensive TypeScript types, intuitive APIs, and extensive documentation + +Our implementation serves as a **foundational building block** for the next generation of decentralized applications, enabling everything from browser-based wallets to server-side JAM node implementations. + +### Project Details + +#### Technology Stack + +- **Programming Language**: **TypeScript** (ES2022+ targeting modern environments) +- **Core Dependencies**: Minimal external dependencies using `@noble/curves` as the audited foundation +- **Testing Framework**: **Vitest** for comprehensive unit, integration, and property-based testing +- **Performance Analysis**: Built-in benchmarking tools for cryptographic operation analysis +- **Documentation**: **JSDoc** with TypeScript integration for comprehensive API documentation +- **Code Quality**: **BiomeJS** for linting, formatting, and code consistency +- **Continuous Integration**: **GitHub Actions** for automated testing, security scanning, and documentation generation +- **Package Management**: **NPM** distribution with proper TypeScript declarations + + +#### Core Components + +Our implementation consists of two complementary packages that together provide complete Bandersnatch VRF functionality: + +##### 1. `@pbnj/bandersnatch`: Foundational Elliptic Curve Package + +**Objective**: Provide a comprehensive, secure, and performant TypeScript library for Bandersnatch elliptic curve cryptography with full RFC 9380 compliance. + +**Deliverables**: +- **Curve Arithmetic & Operations**: + - Complete Bandersnatch curve implementation + - Point addition, scalar multiplication, and field operations + - Point compression/decompression algorithms + - Curve parameter validation and constants + +- **Cryptographic Primitives**: + - Key pair generation and validation + - Point-to-hash conversion functions utilizing Elligator2 + - Curve point serialization/deserialization + - Field element operations and validation + +- **Quality Assurance**: + - Comprehensive unit tests (>90% coverage) + - Performance benchmarks for all operations + - Extensive TypeScript type definitions + - Complete API documentation with examples + +**References**: [Masson, Sanso, and Zhang's Bandersnatch work (ePrint 2021/1152)](https://eprint.iacr.org/2021/1152.pdf), [RFC 9380 - Hashing to Elliptic Curves](https://www.rfc-editor.org/rfc/rfc9380.html) + +##### 2. `@pbnj/bandersnatch-vrf`: Core VRF Implementation Suite + +**Objective**: Implement all major VRF schemes (IETF, Pedersen, Ring) leveraging the foundational bandersnatch package. + +**Deliverables**: + +- **IETF VRF (RFC 9381 Compliant)**: + - Complete ECVRF implementation for Bandersnatch curve + - Support for Bandersnatch_XMD:SHA-512_ELL2_RO_ suite + - Proper domain separation tag (DST) handling + - Verification against official RFC test vectors + - Prover and verifier classes with comprehensive error handling + +- **Pedersen VRF**: + - Full implementation extending IETF VRF patterns + - Optimized for Bandersnatch curve characteristics + - Complete test vector validation + +- **Ring VRF**: + - Complete W3F Ring Proof implementation for Bandersnatch + - KZG polynomial commitment integration + - Ring signature generation and verification + - Privacy-preserving validator selection + +- **Cryptographic Infrastructure**: + - **Elligator2**: Hash-to-curve implementation for Bandersnatch + - **RFC 9381 Compliance**: Complete IETF standard implementation + - **Nonce Generation**: RFC 8032 compliant nonce generation + - **Point Processing**: Gamma point handling and validation + +- **Quality Assurance**: + - End-to-end test suites for all VRF types + - Test vector validation against reference implementations + - Performance benchmarks and optimization analysis + - Comprehensive error handling and edge case coverage + +**References**: [RFC 9381 - Verifiable Random Functions](https://datatracker.ietf.org/doc/html/rfc9381), [W3F Bandersnatch-VRF specification](https://github.com/davxy/bandersnatch-vrf-spec), [W3F Ring-Proof specification](https://github.com/davxy/ring-proof-spec) + +##### 3. `@pbnj/bandersnatch-vrf` Utils: JAM Protocol Specialized Components + +**Objective**: Implement specialized cryptographic utilities for JAM protocol consensus mechanisms and validator operations. + +**Deliverables**: + +- **Entropy VRF**: + - Implements Gray Paper 0.7.2 equation 6.17: `H_vrfsig ∈ bssignature{H_authorbskey}{Xentropy ∥ banderout{H_sealsig}}{[]}` + - Block entropy generation for JAM consensus + - Deterministic randomness derived from seal signatures + +- **Audit VRF**: + - Audit signature generation for validator selection + - Work report hashing and tranche-based randomness + +- **Epoch Root Utilities**: + - KZG polynomial commitments to validator sets + - Ring VRF proof support for validator selection + +- **Gamma Processing Functions**: + - GP `banderout` implementation + - RFC 9381 compliant point-to-hash conversion + - VRF output processing and validation + +**References**: [Gray Paper safrole.tex](https://github.com/gavofyork/graypaper), [Gray Paper auditing.tex](https://github.com/gavofyork/graypaper) + +#### Project Scope - What it IS and IS NOT + +**IS**: A comprehensive TypeScript cryptographic suite providing: +- Complete Bandersnatch elliptic curve implementation with GLV optimizations +- Full IETF VRF, Pedersen VRF, and Ring VRF implementations +- Specialized JAM protocol components (Entropy VRF, Audit VRF, Epoch Root utilities, Gamma processing) +- RFC 9380/9381 compliant hash-to-curve and VRF operations +- Production-ready APIs with comprehensive TypeScript types +- Extensive test suites and performance benchmarks +- Complete documentation and developer guides + +**IS NOT**: +- A full blockchain node or dApp implementation +- A Rust wrapper or language binding +- A system that integrates proofs into specific application logic (though it enables such integrations) +- A formally verified implementation (though it follows cryptographic best practices) +- A third-party audited implementation (though it uses audited dependencies and follows security guidelines) + + +### Ecosystem Fit + +The JAM protocol's success depends on **diverse, robust cryptographic implementations** that enable cross-verification and eliminate single points of failure. Our TypeScript implementation addresses critical ecosystem gaps: + +**Critical Needs Addressed:** +- **Language Diversity**: Extends JAM cryptographic primitives beyond Rust to the entire JavaScript/TypeScript ecosystem +- **Developer Accessibility**: Enables web developers to build JAM-compatible applications without Rust expertise +- **Browser Integration**: Provides cryptographic primitives directly accessible in web browsers +- **Cross-Platform Compatibility**: Ensures consistent behavior across Node.js, browsers, and edge environments + +**Target Applications:** +- **Browser-Based Wallets**: Direct integration of JAM cryptographic primitives in web wallets +- **Light Clients**: Efficient verification of JAM consensus proofs in resource-constrained environments +- **Web Applications**: Seamless integration of JAM randomness and privacy features +- **Developer Tools**: Comprehensive SDKs for JAM application development +- **Research Platforms**: Cryptographic research and protocol experimentation + +**Ecosystem Impact:** +- **Security Enhancement**: Multiple independent implementations enable cross-verification +- **Adoption Acceleration**: Removes language barriers for web developers +- **Innovation Enablement**: Provides additional implementation perspectives for protocol improvements +- **Ecosystem Resilience**: Reduces dependence on single technology stack + + +## Team :busts_in_silhouette: + +### Team members + +- **Mihail Kirov:** + Lead Developer with 5+ years of experience in distributed systems and blockchain integration. Specializes in connecting AI systems with decentralized networks and has a strong track record in open-source contributions. + Mentored at the [Polkadot Prodigy](https://www.linkedin.com/posts/polkadotprodigy_lets-welcome-mihail-kirov-who-is-joining-activity-7191345617330192384-DJbv?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAAC27-YYBCPf5vbQMBXvlthYYXnOflSOp-9A) Hackathon + [GitHub: mikirov](https://github.com/mikirov) | [LinkedIn](https://www.linkedin.com/in/mihail-kirov/) + + +### Contact + +- **Contact Name:** Mihail Kirov +- **Contact Email:** me@mikirov.xyz +- **Website:** [esscrypt.com](https://esscrypt.com/) + +### Legal Structure + +- **Registered Address:** Mladost 3, bl. 313, ent. 3, fl. 10, ap. 66, 1799, Sofia, Bulgaria. +- **Registered Legal Entity:** Escrypt Ltd. + +### Team's experience + +### Team Code Repos + +- [Mihail Kirov](https://github.com/mikirov) + +### Team LinkedIn Profiles + +- [Mihail Kirov](https://www.linkedin.com/in/mihail-kirov/) + +## Development Status :open_book: + +We have conducted preliminary research and have established a solid architectural design for the JAM ElizaOS Plugin. +Initial prototypes and integration experiments with our own PeanutButterAndJAM node have been performed, +and design documents outlining core functionalities, data models, and API specifications are available. +Our prior work on the Polkadot ElizaOS Plugin further validates our technical approach. +Detailed documentation and research findings will be maintained in our repositories and published blog posts. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 30 person-days +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 20,000 USD +- **DOT %:** 50% of total costs + +### Milestone 1 — Core Bandersnatch VRF Implementation + +- **Estimated Duration:** 30 person-days +- **FTE:** 1 FTE +- **Costs:** 10,000 USD + +| Number | Deliverable | Detailed Specification | +|--------|-------------|------------------------| +| **0a.** | **Project Setup & Licensing** | Apache 2.0 license, GitHub repository setup, CI/CD pipeline with GitHub Actions, package.json configuration for NPM distribution | +| **0b.** | **Core Documentation** | JSDoc API documentation, TypeScript type definitions, basic usage examples, and integration guides | +| **0c.** | **Testing Infrastructure** | Comprehensive test suite with >90% coverage, test vector validation, performance benchmarks, and automated testing pipeline | +| **1.** | **Bandersnatch Curve Implementation** | Complete elliptic curve implementation with GLV endomorphism optimization, point arithmetic, field operations, key generation, and curve parameter validation | +| **2.** | **Elligator2 Hash-to-Curve** | RFC 9380 compliant Elligator2 implementation for Bandersnatch curve, supporting both random oracle (RO) and non-uniform (NU) variants | +| **3.** | **IETF VRF Implementation** | Full RFC 9381 ECVRF implementation with Bandersnatch_XMD:SHA-512_ELL2_RO_ suite, proper DST handling, and test vector validation | +| **4.** | **Pedersen VRF Implementation** | Complete Pedersen VRF implementation extending IETF patterns, optimized for Bandersnatch characteristics, with comprehensive test coverage | +| **5.** | **Ring VRF Implementation** | Full W3F Ring Proof implementation with KZG polynomial commitments, ring signature generation/verification, and privacy-preserving validator selection | +| **6.** | **Cryptographic Infrastructure** | RFC 8032 nonce generation, point processing utilities, VRF output validation, and comprehensive error handling with edge case coverage | +| **7.** | **Performance Optimization** | GLV endomorphism implementation, performance benchmarks, optimization analysis, and comparison with reference implementations | +| **8.** | **Core Package Distribution** | NPM package publication, TypeScript declarations, browser compatibility, and cross-platform testing | + +### Milestone 2 — JAM Protocol Specialized Components + +- **Estimated Duration:** 30 person-days +- **FTE:** 1 FTE +- **Costs:** 10,000 USD + +| Number | Deliverable | Detailed Specification | +|--------|-------------|------------------------| +| **1.** | **Entropy VRF Implementation** | Complete implementation of Gray Paper 0.7.2 equation 6.17: `H_vrfsig ∈ bssignature{H_authorbskey}{Xentropy ∥ banderout{H_sealsig}}{[]}` for block entropy generation | +| **2.** | **Audit VRF Implementation** | Full audit signature generation for both tranche 0 and tranche N according to Gray Paper 0.7.2 equations 17.3 and 17.14, including work report hashing | +| **3.** | **Epoch Root Utilities** | Complete implementation of `getRingRoot` function for KZG polynomial commitments to validator sets, supporting ring VRF proofs | +| **4.** | **Gamma Processing Functions** | VRF output processing utilities including `getCommitmentFromGamma`, `getBanderoutFromGamma`, and RFC 9381 compliant point-to-hash conversion | +| **5.** | **JAM Integration Testing** | End-to-end test suites for all JAM protocol components, integration with PeanutButterAndJAM implementation, and real-world usage validation | +| **6.** | **Advanced Documentation** | Comprehensive tutorials for JAM protocol integration, specialized component usage guides, and Gray Paper compliance documentation | +| **7.** | **Performance Analysis** | Specialized benchmarking for JAM protocol components, optimization analysis, and comparison with Rust reference implementations | +| **8.** | **Production Readiness** | Final package distribution, security hardening, edge case handling, and production deployment guidelines | + + +## Future Plans + +### Short-Term (Post-Grant) + +**Community Engagement & Adoption:** +- **Wide Distribution**: Announce library release through JAM community channels, TypeScript cryptography forums, developer conferences, and social media +- **Developer Onboarding**: Publish comprehensive tutorials, integration guides, and example applications +- **JAM Ecosystem Integration**: Present implementation to JAM developers for feedback and adoption in production systems +- **Research Publication**: Submit findings to relevant cryptographic conferences and journals + +**Maintenance & Support:** +- **Active Maintenance**: Monitor GitHub repository for issues, provide bug fixes, and respond to developer queries +- **Compatibility Updates**: Ensure compatibility with upcoming TypeScript versions and Node.js releases +- **Performance Monitoring**: Track performance metrics and optimize based on real-world usage patterns + +**Enhancement & Extension:** +- **Feature Additions**: Implement additional helper functions and utilities based on community feedback +- **Performance Improvements**: Continue optimization efforts and implement advanced techniques +- **Test Vector Generation**: Create comprehensive test vectors compatible with Rust implementations +- **Security Analysis**: Conduct internal security reviews and implement additional hardening measures + +### Long-Term Maintenance & Development + +**Sustained Support Commitment:** +- **Full Compliance**: Maintain full compliance with W3F specifications and any protocol updates for 1 year at no cost +- **Open Source Initiative**: Continue maintenance as part of our open-source contributions beyond the initial year + + +**Ecosystem Expansion:** +- **Integration Partnerships**: Explore integrations with popular TypeScript Web3 tools and SDKs +- **Educational Resources**: Develop educational content and workshops for cryptographic protocol implementation +- **Research Collaboration**: Partner with academic institutions and research organizations for advanced cryptographic research + +**Strategic Development:** +- **Additional VRF Types**: Consider implementing additional VRF schemes based on community needs +- **Formal Verification**: Explore formal verification opportunities for critical components +- **Third-Party Audits**: Pursue professional security audits for production-critical applications +- **Cross-Platform Optimization**: Implement platform-specific optimizations for various JavaScript engines + +### Team's Long-Term Vision + +Our goal is to establish this project as the **definitive TypeScript library** for JAM cryptographic primitives. We envision this implementation becoming the foundation for: + +- **Web-Native JAM Applications**: Browser-based wallets, dApps, and light clients +- **Developer Education**: Comprehensive learning resources for cryptographic protocol implementation +- **Research Platform**: Enabling cryptographic research and protocol experimentation +- **Ecosystem Standard**: Setting the standard for TypeScript cryptographic implementations in the JAM ecosystem + +Success will be measured by **widespread adoption** by developers, **integration** into production JAM applications, and **recognition** as a trusted, secure implementation within the broader cryptographic community. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +- Research into missing TypeScript cryptographic implementations for JAM protocol +- Community discussions about language diversity in JAM ecosystem development + +**Additional Work:** +Our team has previously delivered successful implementations including: +- [ElizaOS Polkadot Plugin](https://github.com/w3f/Grants-Program/pull/2518) - Comprehensive Polkadot integration for AI systems +- **PeanutButterAndJAM**: Active JAM protocol implementation demonstrating real-world usage of our cryptographic libraries + +**Previous Grants:** +- [ElizaOS Polkadot Plugin](https://github.com/w3f/Grants-Program/pull/2518) - Successfully delivered and maintained + +**Technical Expertise:** +- **Cryptographic Implementation**: Deep experience in elliptic curve cryptography and VRF implementations +- **TypeScript Ecosystem**: Extensive knowledge of modern TypeScript development practices and tooling +- **JAM Protocol**: Active contributors to JAM ecosystem through PeanutButterAndJAM implementation +- **Web3 Integration**: Proven track record in blockchain protocol integration and developer tooling \ No newline at end of file diff --git a/applications/Banksy_Finance.md b/applications/Banksy_Finance.md index ad722469931..da109029248 100644 --- a/applications/Banksy_Finance.md +++ b/applications/Banksy_Finance.md @@ -1,6 +1,4 @@ -# Open Grant Proposal - -* **Project:** Banksy Finance +# Banksy Finance * **Proposer:** Clink Li diff --git a/applications/CESS.md b/applications/CESS.md index adb24f866cf..28b2d83c6e3 100644 --- a/applications/CESS.md +++ b/applications/CESS.md @@ -1,22 +1,17 @@ -# W3F Open Grant Proposal - - -* **Project Name:** Cumulus Encrypted Storage System (CESS) -* **Team Name:** CESS LAB -* **Payment Address:** 0x378D889a6e66996C9Eda86D20D7E6adE666ce167(USDT) -* **Level:** 1 +# Cumulus Encrypted Storage System (CESS) +- **Team Name:** CESS LAB +- **Payment Address:** 0x378D889a6e66996C9Eda86D20D7E6adE666ce167(USDT) +- **Level:** 1 ## Project Overview :page_facing_up: - ### Overview -* Tag line: An infrastructure for a blockchain-based decentralized cloud data network. -* Brief description: Cumulus Encrypted Storage System (CESS) is dedicated to develop a new global decentralized cloud data storage platform – a blockchain-based network infrastructure that is transparent, efficient, and equal opportunity to all members of the global community. CESS encourages excess or under-utilized resources as nodes to join CESS’s unrestricted expandable network via the token economy incentive method. Each node joins the CESS peer-to-peer network by contributing data storage resources, computational resources, or network bandwidth. Built on our state-of-the-art virtualization and cloud computing technologies, CESS organizes and manages the participating resources providing clients with secure, high performance, and boundless cloud data storage services. Furthermore, the CESS protocol enables interconnection of network nodes, to build a large decentralized cloud storage system that supports up to 100PB storage scale to meet the demand of enterprise level data storage. CESS will adopt a phased approach to implement the above goals. -* Indication 1: With the goal of entering Polkadot ecosystem, CESS will build a blockchain system based on Substrate directly, and plans to develop custom pallets on FRAME. In the future, CESS will consider integrating to Polkadot in the form of Parachain to create a new decentralized cloud storage ecosystem, establish a large-scale distributed storage network. -* Indication 2: With rapid advances of new computing technologies such as big data and machine learning, the value of humanity’s digital assets, the so-called “Digital Gold”, are being discovered. Explosively growing amount of data in cyberspace calls for new technologies of secure data storage and efficient data sharing. The challenges are to achieve secure storage, efficient sharing, and trading with data owner’s rights protection, but current solutions are complex and worrisome. Distributed storage networks can better drive the arrival of Web3.0 and are one of the underlying technical infrastructure of Web3.0. - +- Tag line: An infrastructure for a blockchain-based decentralized cloud data network. +- Brief description: Cumulus Encrypted Storage System (CESS) is dedicated to develop a new global decentralized cloud data storage platform – a blockchain-based network infrastructure that is transparent, efficient, and equal opportunity to all members of the global community. CESS encourages excess or under-utilized resources as nodes to join CESS’s unrestricted expandable network via the token economy incentive method. Each node joins the CESS peer-to-peer network by contributing data storage resources, computational resources, or network bandwidth. Built on our state-of-the-art virtualization and cloud computing technologies, CESS organizes and manages the participating resources providing clients with secure, high performance, and boundless cloud data storage services. Furthermore, the CESS protocol enables interconnection of network nodes, to build a large decentralized cloud storage system that supports up to 100PB storage scale to meet the demand of enterprise level data storage. CESS will adopt a phased approach to implement the above goals. +- Indication 1: With the goal of entering Polkadot ecosystem, CESS will build a blockchain system based on Substrate directly, and plans to develop custom pallets on FRAME. In the future, CESS will consider integrating to Polkadot in the form of Parachain to create a new decentralized cloud storage ecosystem, establish a large-scale distributed storage network. +- Indication 2: With rapid advances of new computing technologies such as big data and machine learning, the value of humanity’s digital assets, the so-called “Digital Gold”, are being discovered. Explosively growing amount of data in cyberspace calls for new technologies of secure data storage and efficient data sharing. The challenges are to achieve secure storage, efficient sharing, and trading with data owner’s rights protection, but current solutions are complex and worrisome. Distributed storage networks can better drive the arrival of Web3.0 and are one of the underlying technical infrastructure of Web3.0. ### Project Details @@ -24,102 +19,108 @@ We expect the teams to already have a solid idea about your project's expected f Mockups/designs of any UI components -* Global nodes: Display the global map and the number of global nodes of distributed storage network, and mark the location distribution of nodes according to coordinates; Display node list. +- Global nodes: Display the global map and the number of global nodes of distributed storage network, and mark the location distribution of nodes according to coordinates; Display node list. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img1.png) -* My cloud disk: Personal storage space to view the files uploaded to the storage network; The list can be sorted by upload time, file name, file type and file size; Supports file download, share, property setting, deletion and other operations. +- My cloud disk: Personal storage space to view the files uploaded to the storage network; The list can be sorted by upload time, file name, file type and file size; Supports file download, share, property setting, deletion and other operations. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img2.png) -* File upload: Select the files to be stored and set the relevant storage parameters. +- File upload: Select the files to be stored and set the relevant storage parameters. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img3.png) -* Search for file: Search the whole network through keywords, and download the search results. +- Search for file: Search the whole network through keywords, and download the search results. ![Image](https://raw.githubusercontent.com/Cumulus2021/W3F-illustration/main/img4.png) Documentation of core components, protocols, architecture, etc. to be deployed -* CESS is a high-speed, secure, scalable and decentralized cloud storage system. It can handle tens of thousands of transactions per second through parallel technology. Through Data slicing technology, it can achieve the secure storage of massive data, and it has the functions of Data confirmation and Data rights protection, which provides powerful data service ability. It provides DAPP with unlimited scalable storage capacity and perfect Data rights protection capability. +- CESS is a high-speed, secure, scalable and decentralized cloud storage system. It can handle tens of thousands of transactions per second through parallel technology. Through Data slicing technology, it can achieve the secure storage of massive data, and it has the functions of Data confirmation and Data rights protection, which provides powerful data service ability. It provides DAPP with unlimited scalable storage capacity and perfect Data rights protection capability. + +- Data storage workflow: When a client requests to store a data file, the CESS platform pre-processes the data file to obtain and store its meta-data and data fingerprints. The pre-process software also performs data file replication and fault tolerant erasure coding. The meta-data includes info of data owner, data keywords, and etc. The data fingerprints are for subsequent data rights confirmation. + +
+ +- CESS client-platform interactions: A typical CESS data client and platform interaction flow is as follows: first, a data storage client interrogates CESS chain to get current storage price. The client then places an order for his/her data file via extrinsics on blockchain. Once the payment is made and order is approved, the client then uploads the data file using API provided by CESS platform. The data file is not directly uploaded to storage nodes, instead it is uploaded to a CESS storage scheduling node. The scheduling nodes are the ones with secure hardware environment (Trusted Execution Environment or TEE) and the data file will be pre-processed, encrypted, and sharded. Finally, the scheduling node distributes data segments to storage nodes to store. CESS storage miners do not make deal directly with clients, and they get rewarded from CESS system by providing storage space. Miners’ storage resources are uniformly managed by CESS system, which fairly distributes data files. Miners have the responsibility to maintain the integrity of clients’ data. Any malicious behavior will be punished (CESS token deduction). + +
-* Data storage workflow: When a client requests to store a data file, the CESS platform pre-processes the data file to obtain and store its meta-data and data fingerprints. The pre-process software also performs data file replication and fault tolerant erasure coding. The meta-data includes info of data owner, data keywords, and etc. The data fingerprints are for subsequent data rights confirmation. -
+- Overall system architecture: CESS adopts a layered and loosely coupled system architecture, which is divided into blockchain service layer, distributed storage resource layer, distributed content delivery layer and application layer. -* CESS client-platform interactions: A typical CESS data client and platform interaction flow is as follows: first, a data storage client interrogates CESS chain to get current storage price. The client then places an order for his/her data file via extrinsics on blockchain. Once the payment is made and order is approved, the client then uploads the data file using API provided by CESS platform. The data file is not directly uploaded to storage nodes, instead it is uploaded to a CESS storage scheduling node. The scheduling nodes are the ones with secure hardware environment (Trusted Execution Environment or TEE) and the data file will be pre-processed, encrypted, and sharded. Finally, the scheduling node distributes data segments to storage nodes to store. CESS storage miners do not make deal directly with clients, and they get rewarded from CESS system by providing storage space. Miners’ storage resources are uniformly managed by CESS system, which fairly distributes data files. Miners have the responsibility to maintain the integrity of clients’ data. Any malicious behavior will be punished (CESS token deduction). -
+
-* Overall system architecture: CESS adopts a layered and loosely coupled system architecture, which is divided into blockchain service layer, distributed storage resource layer, distributed content delivery layer and application layer. -
+- CESS MDRC mechanism workflow: CESS have designed a unique **Multi-format Data Rights Confirmation Mechanism (MDRC)**, which extracts data fingerprint from each data file to generate data certificate ID. By comparing similarities between data fingerprints, the system identifies data lineages of data files, and may take appropriate actions to prevent possible violations, and to provide strong evidences for owners’ data rights protection. -* CESS MDRC mechanism workflow: CESS have designed a unique **Multi-format Data Rights Confirmation Mechanism (MDRC)**, which extracts data fingerprint from each data file to generate data certificate ID. By comparing similarities between data fingerprints, the system identifies data lineages of data files, and may take appropriate actions to prevent possible violations, and to provide strong evidences for owners’ data rights protection. -
+
### Ecosystem Fit CESS is a distributed cloud data network with user friendly ledgers, novel consensus mechanism, multiple data authenticity proof schemes, and reliable network infrastructure. CESS offers data storage service with the advantages of low cost, privacy protection, security and robustness. With the implementation of CESS data confirmation and proxy re-encryption technology, CESS provides Web3.0 clients and DAPPs with trustworthy, secure and reliable data rights protection. Compared to the similar projects in the Polkadot ecosystem including Ocean, DataHighway and Bluzelle, CESS storage service features: -* Encrypted data storage -* Multiple copies (3 copies by default, more upon request) -* Sharded and distributed on multiple nodes -* Highly scalable storage space -* Transactions secured by CESS blockchain -* Data rights protection for data owners -* Competitive cost + +- Encrypted data storage +- Multiple copies (3 copies by default, more upon request) +- Sharded and distributed on multiple nodes +- Highly scalable storage space +- Transactions secured by CESS blockchain +- Data rights protection for data owners +- Competitive cost ## Team :busts_in_silhouette: ### Team members -* Joseph Li -* Jinghong Zeng +- Joseph Li +- Jinghong Zeng ### Contact -* **Contact Name:** Jessie Dai -* **Contact Email:** jessie@cess.cloud -* **Website:** http://cess.cloud +- **Contact Name:** Jessie Dai +- **Contact Email:** jessie@cess.cloud +- **Website:** http://cess.cloud ### Legal Structure -* **Registered Address:** 22 St Leonard's Ave, Lostock, Bolton BL6 4JE, England -* **Registered Legal Entity:** Paul David Humphreys +- **Registered Address:** 22 St Leonard's Ave, Lostock, Bolton BL6 4JE, England +- **Registered Legal Entity:** Paul David Humphreys ### Team's experience -* Team CESS +- Team CESS -CESS technical team members have an affluent understanding of technology and have been involved in internationally renowned cloud storage companies as essential technical development members. +CESS technical team members have an affluent understanding of technology and have been involved in internationally renowned cloud storage companies as essential technical development members. The background of our team members includes but not limited to cloud computing and storage, involved in cloud related PaaS and SaaS products research and development; unique insights into the network development, cryptography algorithm implementation, and performance optimization; comprehensive knowledge of public chain and played a major role in the development of public chain focusing on the delivery of commercial applications. For the past two years, CESS core team members have been developing and building a stable decentralized cloud storage service atop the distributed resources to surmount the security risks presented in the current centralized storage platform. The members are working in the UK, China, and India locations with the commitment creating a decentralized cloud storage data network for commercial use. -* Joseph Li + +- Joseph Li Joseph Li brings to our operations 24 years of experiences as a Principal Network Engineer managing and supporting large-scale networks on a global scale. Amongst Joseph’s numerous achievements was the IP infrastructure conversion for a network of over 900 nodes and his major accomplishments within the field of VPN. -* Jinghong Zeng + +- Jinghong Zeng Jinghong Zeng served more than 20 years with a global telecommunications cooperation as a Senior System Architect and Software Engineer, she has proven skills in data warehousing, data processing within distributed systems and a solid understanding of Blockchain. ### Team Code Repos -* https://github.com/Cumulus2021/CumulusSystem -* https://github.com/Cumulus2021/Whitepaper +- https://github.com/Cumulus2021/CumulusSystem +- https://github.com/Cumulus2021/Whitepaper ## Development Roadmap :nut_and_bolt: - ### Overview -* **Total Estimated Duration:** 4 months -* **Full-Time Equivalent (FTE):** 2 -* **Total Costs:** 8,000 USD +- **Total Estimated Duration:** 4 months +- **Full-Time Equivalent (FTE):** 2 +- **Total Costs:** 8,000 USD ### Milestone 1: Implement Substrate Modules -* **Estimated Duration:** 2 months -* **FTE:** 2 -* **Costs:** 4,000 USD +- **Estimated Duration:** 2 months +- **FTE:** 2 +- **Costs:** 4,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -132,12 +133,11 @@ Jinghong Zeng served more than 20 years with a global telecommunications coopera | 1c. | Substrate module: Storage Miner | We will create a Substrate module that will process and upload user data, and support Integrity verification. | | 2. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain. | - ### Milestone 2: Implement Storage Mining -* **Estimated Duration:** 1 month -* **FTE:** 2 -* **Costs:** 2,000 USD +- **Estimated Duration:** 1 month +- **FTE:** 2 +- **Costs:** 2,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -146,16 +146,15 @@ Jinghong Zeng served more than 20 years with a global telecommunications coopera | 0c. | Testing Guide | The code will have unit-test coverage (min. 80%) to ensure functionality and robustness. In the guide we will describe how to run these tests. | | 0d. | Article/Tutorial | We will publish an article and a tutorial that explains the work done as part of the grant. | | 1a. | Stacked DRG Library | We will create a library for proving and verifying transactions, compatible with the substrate pallet. | -| 1b. | zk-SNARK proofs | We will implement the algorithm to process the proof results from stacked DRG library. | -| 2. | Substrate module: Segment Book | Develop pallet implement function of storage mining. | -| 3. | Miner Client | Interactive with pallet for storage mining to implement mining supporting services. | - +| 1b. | zk-SNARK proofs | We will implement the algorithm to process the proof results from stacked DRG library. | +| 2. | Substrate module: Segment Book | Develop pallet implement function of storage mining. | +| 3. | Miner Client | Interactive with pallet for storage mining to implement mining supporting services. | ### Milestone 3: Implement and Integrate CESS Applications -* **Estimated Duration:** 1 month -* **FTE:** 2 -* **Costs:** 2,000 USD +- **Estimated Duration:** 1 month +- **FTE:** 2 +- **Costs:** 2,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -164,11 +163,10 @@ Jinghong Zeng served more than 20 years with a global telecommunications coopera | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. | | 0d. | Article/Tutorial | We will publish an article and a tutorial that explains the work done as part of the grant. | | 1. | Cryptographic modules | We will implement the cryptographic modules including inner product functional encryption and the associated zero-knowledge proof for storage proof. | -| 2. | UI Modules | We will design a user-friendly UI that supports both PC and mobile. | -| 3. | File processing | We provide abundant file operation services, including file upload, download, share, delete, etc. | -| 4. | Benchmark | Perform unit tests on the individual algorithms to ensure system safety. | -| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain. | - +| 2. | UI Modules | We will design a user-friendly UI that supports both PC and mobile. | +| 3. | File processing | We provide abundant file operation services, including file upload, download, share, delete, etc. | +| 4. | Benchmark | Perform unit tests on the individual algorithms to ensure system safety. | +| 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of our chain. | ## Future Plans diff --git a/applications/CILA-omnichain-infrastructure.md b/applications/CILA-omnichain-infrastructure.md new file mode 100644 index 00000000000..227987718b2 --- /dev/null +++ b/applications/CILA-omnichain-infrastructure.md @@ -0,0 +1,512 @@ +# CILA - Omnichain Infrastructure + +- **Team Name:** Collective Intelligence Labs +- **Payment Address:** bc1qff0kjc6pyjkneyt3pctm5nahjpd9f774avz55x (BTC) +- **Level:** 2 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1679#issuecomment-1823419675) + +## Project Overview :page_facing_up: + +### Overview + +The goal of this project is to implement an omnichain smart contract infrastructure support for Substrate framework. 🌐🤖 This will include the implementation of CQRS + Event Sourcing execution environment plus an example smart-contract. The implementation will be done using WASM and/or native Rust Substrate implementation as a pallet. The implementation will include implementing Protobuf support on-chain, serialization/deserialization, aggregated repository, event store, command/operations dispatcher, and events emitter. 🛠️👨‍💻 + +### Introduction + +This project aims to add an omnichain smart contract infrastructure support for Substrate framework by implementing a CQRS + Event Sourcing execution environment. CQRS (Command Query Responsibility Segregation) is a design pattern that separates the command and query responsibilities of an application. Event Sourcing is a design pattern that represents the state of an application as a series of events that are stored in an event store. 🧬💻 + +### Implementation +The implementation of the omnichain smart contract infrastructure will be done using WASM and/or native Rust Substrate implementation as a pallet. The implementation will include the following components: + +#### Protobuf support on-chain +Protobuf is a language-agnostic binary serialization format that allows developers to define structured data schemas. The implementation will include support for Protobuf on-chain, which will enable developers to define smart contract interfaces using Protobuf. 🤖💾 + +#### Aggregate Repository +Aggregate Repository is a data storage module that manages the state and storage of aggregate objects. It provides methods for creating, reading, updating, and deleting aggregates. 📈📊 + +#### Event Store +An event store is a database that stores events in the order they occurred. The implementation will include an event store, which will store all the events generated by the smart contract. 🗂️📑 + +#### Command/operations Dispatcher +A command/operations dispatcher is a component that receives commands/operations and dispatches them to the appropriate handler. The implementation will include a command/operations dispatcher, which will enable developers to define command/operation handlers for the smart contract. 🚚👨‍✈️ + +#### Events Emitter +An events emitter is a component that emits events. The implementation will include an events emitter, which will enable developers to define event handlers for the smart contract. 📣🔊 + +## Conclusion +The completion of this project will provide a powerful infrastructure for developers to build customized omnichain smart contracts on the Substrate framework. 💪👨‍💼 + +![architecture](https://i.imgur.com/QsmzpZR.png) + +## 🚀 Technology Stack + +**Programming Language** - Rust 🦀 + +**Blockchain Framework** - Substrate ⛓️ + +**Virtual Machine** - WebAssembly (WASM) 🕸️ + +**Serialization** - Protocol Buffers (protobuf) 📜: a language-agnostic data serialization format that allows for efficient and interoperable communication between different services and systems. + +**Design Patterns**: +- Event Sourcing 📝: a pattern that captures all changes to an application state as a sequence of events, which can be used to reconstruct the state at any point in time. +- Command Query Responsibility Segregation (CQRS) 🧬: a pattern that separates the read and write concerns of an application, using separate models and interfaces for each. +- Saga pattern 🌟: a pattern for coordinating distributed transactions across multiple services, ensuring consistency and reliability. +- Domain-Driven Design (DDD) 🏰: a design approach that emphasizes the importance of the domain model in shaping the architecture of a software system. + +**Database** - MongoDB 🗄️: a NoSQL document database that provides scalability, flexibility, and high availability. + +**Testing Framework** - Rust Testing 🧪: Rust has an inbuilt testing framework that enables testing of units of code in isolation. + +**CI/CD** - GitHub Actions 🚀: a continuous integration and continuous deployment service that can automate the build and deployment processes. + +**Containerization** - Docker 🐳: a tool that allows for the creation, deployment, and running of applications in containers, providing a consistent runtime environment across different platforms. + + +# Documentation for Core Copmpontents + +# Dispatcher + +The `Dispatcher` is a component of the omnichain smart contract infrastructure that receives commands/operations and dispatches them to the appropriate handler. The `Dispatcher` class enables developers to define command/operation handlers for the smart contract. + +## Usage + +The `Dispatcher` can be used in the implementation of the CQRS + Event Sourcing execution environment for Substrate framework. It receives commands/operations from external sources, such as a client or a node, and routes them to the appropriate command/operation handler. + +To use the `Dispatcher`, developers first define a set of command/operation handlers for the smart contract. These handlers can be implemented as methods in a Rust struct. The `Dispatcher` class then instantiates this struct and routes commands/operations to the appropriate method based on the type of command/operation. + +## Benefits + +The `Dispatcher` provides a simple and flexible way to handle commands/operations in the smart contract. By defining a set of command/operation handlers, developers can easily add new functionality to the smart contract without having to modify the `Dispatcher` class itself. + +In addition, the `Dispatcher` enables developers to implement complex business logic in the smart contract by routing commands/operations to the appropriate handler. This allows for a more modular and maintainable codebase. + +## Conclusion + +The `Dispatcher` is a crucial component of the omnichain smart contract infrastructure. By enabling developers to define command/operation handlers for the smart contract, it provides a simple and flexible way to handle commands/operations. Its usage in the implementation of the CQRS + Event Sourcing execution environment for Substrate framework enables developers to implement complex business logic in a modular and maintainable codebase. + +# EventStore + +## Description + +The `EventStore` is a database that stores events in the order they occurred. It is a crucial component of the omnichain smart contract infrastructure support for Substrate framework. The `EventStore` class enables the storage of all events generated by the smart contract, allowing for a complete historical record of all transactions and changes to the smart contract's state. + +## Implementation + +The `EventStore` is implemented using an internal Substrate database. The `EventStore` stores events in the form of serialized binary data plus metadata, which can be easily deserialized for querying and analysis. + +## Features + +The `EventStore` includes the following features: + +- **Event storage:** The `EventStore` stores all events generated by the smart contract in the order they occurred, allowing for a complete historical record of all transactions and changes to the smart contract's state. + +- **Querying:** The `EventStore` allows for easy querying of events using various criteria, such as time range, event type, or specific parameters. + +- **Deserialization:** The `EventStore` can easily deserialize stored binary data for querying and analysis. + +- **Scalability:** The `EventStore` can handle large volumes of events and is designed for scalability. + +## Benefits + +The `EventStore` provides several benefits to developers building smart contracts on the Substrate framework, including: + +- **Transparency:** The `EventStore` provides a complete historical record of all transactions and changes to the smart contract's state, ensuring transparency and accountability. + +- **Auditability:** The `EventStore` allows for easy querying and analysis of events, enabling developers to audit the smart contract's behavior and ensure compliance with regulations and business rules. + +- **Flexibility:** The `EventStore` can handle a wide range of event types and is designed for scalability, providing flexibility for developers building smart contracts on the Substrate framework. + +## Conclusion + +The `EventStore` is a crucial component of the omnichain smart contract infrastructure support for Substrate framework. It provides event storage, querying, deserialization, and scalability features, enabling developers to build transparent, auditable, and flexible smart contracts on the Substrate framework. The completion of this project will provide a powerful infrastructure for developers to build customized smart contracts on the Substrate framework, with the `EventStore` serving as a key component of this infrastructure. + +# Snapshot Store + +## Overview +The `Snapshot Store` is a component of the omnichain smart contract infrastructure that provides a way to store and retrieve snapshots of the smart contract state. A snapshot is a read-only view of the smart contract state at a particular point in time. Snapshots are useful for optimizing the performance of the smart contract by reducing the amount of data that needs to be read from the event store. + +## Implementation +The implementation of the `Snapshot Store` includes the following components: + +- `Snapshot Store`: The Snapshot Store is the primary component. It provides an interface for storing and retrieving snapshots of the smart contract state. +- `Snapshot Index`: The Snapshot Index is a data structure that is used to index snapshots by their version. It allows for efficient retrieval of the latest snapshot. +- `Snapshot Writer`: The Snapshot Writer is a component that is used to write snapshots to the Snapshot Store. It receives the current state of the smart contract and writes it to the Snapshot Store as a snapshot. +- `Snapshot Reader`: The Snapshot Reader is a component that is used to read snapshots from the Snapshot Store. It receives a snapshot version and returns a read-only view of the smart contract state at that version. + +## Conclusion +The `Snapshot Store` provides a way to store and retrieve snapshots of the smart contract state, which can be used to optimize the performance of the smart contract. The implementation includes the `Snapshot Store`, `Snapshot Index`, `Snapshot Writer`, and `Snapshot Reader` components. The completion of this component will provide a pefrormance optmization for omnichain smart contracts on the Substrate framework. + +# Aggregate + +The `Aggregate` is a core component of the CQRS + Event Sourcing design pattern. It represents the current state of an entity and is responsible for handling commands and producing events. + +## Description + +An `Aggregate` is a stateful object that represents a single entity in the system. It maintains its state by applying events to its internal state. A new state can be generated by applying new events to the existing state. + +In the context of the Substrate framework, an `Aggregate` is implemented as a Rust struct that contains its internal state and a set of methods to apply events and handle commands. + +## Implementation + +The `Aggregate` is implemented using the following components: + +### Internal state + +The internal state of an `Aggregate` is represented as a Rust struct. The struct contains all the data necessary to represent the current state of the entity. + +### Command handling + +The `Aggregate` contains a set of methods to handle commands. These methods accept a command object as input and return a set of events that represent the result of executing the command. + +### Event sourcing + +The `Aggregate` implements event sourcing by maintaining a list of events that have been applied to the internal state. When a new command is received, the `Aggregate` applies the appropriate events to generate a new state. + +### Snapshotting + +The `Aggregate` implements snapshotting by periodically storing a snapshot of its internal state. When an `Aggregate` is retrieved from its event stream, it can be initialized with the latest snapshot and then apply only the events that occurred after the snapshot. + +## Conclusion + +The `Aggregate` is a core component of the CQRS + Event Sourcing design pattern. It represents the current state of an entity and is responsible for handling commands and producing events. The implementation of the `Aggregate` in the Substrate framework provides a powerful mechanism for building complex and scalable smart contracts. + + +# AggregateState + +The `AggregateState` represents the state of an aggregate object in the event sourcing pattern. It is responsible for maintaining the current state of the aggregate object by processing the events that have occurred in the past. + +### Properties + +- `id`: The unique identifier of the aggregate object. +- `version`: The version of the aggregate object. +- `events`: The list of events that have occurred in the past. + +### Methods + +- `apply_event(event)`: Applies the given event to the current state of the aggregate object. This method updates the state of the aggregate object based on the event that occurred. +- `get_version()`: Returns the version of the aggregate object. +- `get_events()`: Returns the list of events that have occurred in the past. + +### Usage + +To use the `AggregateState` , you must first create an instance of it and initialize it with the current state of the aggregate object. You can then apply events to the aggregate object by calling the `apply_event()` method. + +## Diagramm + +Architecture Overview Diagram +![Diagramm](https://i.imgur.com/nWGtuEc.png) + +Flow Diagramm + +![Diagramm](https://i.imgur.com/1jeLNo1.png) + +Command Processing Flow Diagramm + +```sql + +------------+ +------------+ +-----------------+ +-------------------+ +------------+ + | Application| | Router | | Execution Chain | | Event Relay Node | | Aggregation| + +------------+ +------------+ +-----------------+ +-------------------+ +------------+ + | | | | | + | Command Request | | | | + |------------------>| | | | + | | | | | + | Command Handler | | | | + |------------------>| | | | + | | Command Request | | | + | |------------------->| | | + | | | Execute Command (CQRS) | | + | | |--------------------------->| | + | | | | Store Event (ES) | + | | | |----------------------------->| + | | | | | + | | | | Broadcast Event to | + | | | | Other Chains | + | | | |--------------------------->| + | | | | | + | | | | Transmit Event to | + | | | | Aggregation Cluster | + | | | |----------------------------->| + | | | | | + | | | | Process Events and | + | | | | Produce Aggregated Data | + | | | |<-----------------------------| + | | | | | + | | | | Return Aggregated Data | + | | | |<-----------------------------| + | | | | | + +``` + +# API Documentation + +## Domain + +### Aggregate + +#### `AggregateState` + +##### Methods + +* `new() -> Self`: Creates a new instance of `AggregateState`. +* `apply_events(&mut self, events: Vec) -> Result<(), String>`: Applies a list of domain events to the aggregate state. +* `clear(&mut self)`: Clears the state of the aggregate. + +#### `DomainEvent` + +##### Methods + +* `new(evnt_type: DomainEventType, evnt_payload: Vec) -> Self`: Creates a new instance of `DomainEvent`. +* `serialize(&self) -> Result, String>`: Serializes the domain event to a byte array. + +#### `DomainEventType` + +##### Variants + +* `NFT_MINTED` +* `NFT_TRANSFERED` + +### Entities + +#### `NFT` + +##### Fields + +* `hash: [u8; 32]`: The unique hash of the NFT. +* `owner: Address`: The address of the owner of the NFT. + +##### Methods + +* `new(hash: [u8; 32], owner: Address) -> Self`: Creates a new instance of `NFT`. +* `get_hash(&self) -> [u8; 32]`: Returns the hash of the NFT. +* `get_owner(&self) -> Address`: Returns the owner of the NFT. +* `transfer(&mut self, new_owner: Address)`: Transfers the ownership of the NFT to a new owner. + +## Application + +### Command + +#### `Command` + +##### Fields + +* `cmd_type: CommandType` +* `cmd_payload: Vec` + +##### Methods + +* `new(cmd_type: CommandType, cmd_payload: Vec) -> Self`: Creates a new instance of `Command`. +* `serialize(&self) -> Result, String>`: Serializes the command to a byte array. + +#### `CommandType` + +##### Variants + +* `MINT_NFT` +* `TRANSFER_NFT` + +### Service + +#### `CommandDispatcher` + +##### Methods + +* `dispatch(command: Command) -> Result<(), String>`: Dispatches a command to the appropriate handler. + +#### `NFTService` + +##### Fields + +* `state: NFTsState` +* `event_store: Box` +* `dispatcher: Box` + +##### Methods + +* `new(state: NFTsState, event_store: Box, dispatcher: Box) -> Self`: Creates a new instance of `NFTService`. +* `handle_command(&mut self, command: Command) -> Result<(), String>`: Handles a command by dispatching it to the appropriate handler. +* `get_nft_owner(&self, hash: [u8; 32]) -> Option
`: Returns the owner of an NFT with the given hash. + +### Event + +#### `DomainEventType` + +##### Variants + +* `NFT_MINTED` +* `NFT_TRANSFERED` + +#### `DomainEvent` + +##### Fields + +* `evnt_type: DomainEventType` +* `evnt_payload: Vec` + +##### Methods + +* `new(evnt_type: DomainEventType, evnt_payload: Vec) -> Self`: Creates a new instance of `DomainEvent`. +* `serialize(&self) -> Result, String>`: Serializes the domain event to a byte array. + +### Store + +#### `AggregateRepository` + +##### Fields + +* `event_store: Box` + +##### Methods + +* `new(event_store: Box) -> Self`: Creates a new instance of `AggregateRepository + +🌟 **Ecosystem Fit:** 🌟 + +🔹 **Project's Fit:** CILA will provide an infrastructure for building efficient omnichain smart contracts that can be integrated into the Polkadot ecosystem, offering a unique solution in the Substrate/Polkadot/Kusama landscape. + +🔹 **Target Audience:** Developers interested in building omnichain smart contracts on Substrate, Polkadot, and Kusama, particularly those looking to develop cross-chain applications and interact with multiple blockchain networks. + +🔹 **Project's Purpose:** The infrastructure will enable developers to build more efficient and scalable omnichain smart contracts, making it easier to create cross-chain applications that interact with multiple blockchain networks. This will help solve the problem of siloed blockchains and allow developers to take advantage of the benefits of multiple chains. + +🔹 **Similar Projects:** We are not aware of any other projects similar to OmniChain in the Substrate/Polkadot/Kusama ecosystem, offering a unique solution for building omnichain smart contracts. + +## Team 🦾 + +### Team members + +- 👨‍💻 Alex Shkor - Architect, Developer, Team Lead +- 👨‍💻 Alexey Kulik - Architect, Developer +- 👩‍💼 Julia Shinkevich - Project Manager +- 🧑‍💼 Max Slyzkoukh - Product Manager +- 👨‍🔧 Yahor Tsaryk - Engineer + + +### Contact + +- **Contact Name:** Alex Shkor +- **Contact Email:** alex@cilabs.ai +- **Website:** https://collectiveintelligence.dev/ + +### Legal Structure + +- **Registered Address:** 16192 Coastal Highway, Lewes, DE 19958, United States. +- **Registered Legal Entity:** Collective Intelligence Labs Inc. + +### Team's experience + +Our team's extensive experience in blockchain development and past successful projects make us well-suited for this project. We have developed several blockchain-based platforms, including DeSci, which offers a decentralized scientific communication infrastructure, and IPledger, which registers intellectual property assets on the blockchain. We have also built a Proof of Share protocol for verification on a chain that specific files have been shared between parties, an on-chain grants distribution platform, a decentralized technology transfer platform, [F-NFT](https://github.com/DEIPworld/deip-node/tree/develop/pallets/deip_f_nft) and [Event Proxy](https://github.com/DEIPworld/deip-node/tree/develop/event-proxy) for Substrate, and other projects. + +Our team members have also contributed to open-source blockchain projects, demonstrating our commitment to the development of the blockchain ecosystem as a whole. + +Our Team Lead is distributed systems architect and has over 14 years of experience in this field, with one of our team members being the inventor of omnichain smart-contracts protocol, which is an important aspect of this project. Our Software Engineer has over 10 years of experience in distributed systems engineering and was the ex-CTO at DEIP and the creator of the Economy Protocol. Our Tech Lead has experience in distributed system and blockchain R&D and was the ex-Head of R&D at Paralect, while also having experience as an ex-CPO at DEIP. Our Head of Marketing has 9 years of experience in PR and communications, having worked with micromobility and web3 startups. Our Product Manager expert in digital transformation has 6 years of experience in the procurement of 50+ leading private and state Ukrainian enterprises. + +As a team, we have previously applied for a grant from the web3 foundation grants program for our DEIP project (DEIPWORLC Inc. legal entity). However, due to the constantly evolving market landscape and changing needs of the industry, we decided to pivot multiple times, and therefore did not deliver original proposal fully (only about 50% of it - onchain part). During the process we realized that on-chain IP management would not be possible without other infrastructure part. Therefore we decided to completely stop [previous project](https://github.com/DEIPworld), change our focus and start working on a diferent solution, the core solution that will make possible to implement DEIP and other our projects that rely on omni-chain infrastructure and onchain IP management - omni-chain infrastructure + +We believe that being transparent about our previous application and pivot is important. We want to assure the committee that we are committed to delivering the proposed solution for our current application, and that we are passionate about creating value in the blockchain ecosystem. + +We are confident that our team's expertise and experience in developing distributed systems and infrastructure will enable us to successfully execute our proposed CILA omnichain infrastructure project. We believe that this infrastructure is crucial for the growth and adoption of blockchain technology, and we are excited about the opportunity to contribute to this space. + +### Team Code Repos + +- https://github.com/Collective-Intelligence-Labs + +### Team GitHub Profiles + + +- https://github.com/alexshkor +- https://github.com/aliakseikulik +- https://github.com/yahortsaryk +- https://github.com/juliacil + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/alexshkor/ +- https://www.linkedin.com/in/alexeykulik/ +- https://www.linkedin.com/in/julia-shinkevich/ +- https://www.linkedin.com/in/max-slyzkouh/ +- https://www.linkedin.com/in/yahor-tsaryk-92032a68/ + + +## Development Status :open_book: + +CILA omnichain infrastructure for Substrate is currently in the research and planning phase. We have conducted extensive research on the existing smart contract infrastructure and identified the need for an omnichain smart contract solution. Our team has also analyzed the capabilities of the Substrate/Polkadot/Kusama ecosystem and determined that it is the ideal platform for building this solution. + +We have created a detailed project plan that outlines the development roadmap and milestones. This plan includes research and development of the necessary components. + +- Draft of solidity implementation: https://github.com/Collective-Intelligence-Labs/cila-sol-contracts +- Vision Paper: https://docsend.com/view/eqt2iazwmff3jikh + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 30,000 USD + +### Milestone 1 — Design and Implementation + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | + **0b.** | Documentation | We will ensure comprehensive documentation of the code by providing both inline comments and a step-by-step tutorial. This tutorial will guide the user through spinning up a Substrate-based execution environment for the CILA Omnichain Infrastructure and testing omnichain transactions, showcasing the new functionality. | +| **0c.** | Testing and Testing Guide | We will conduct comprehensive unit testing on the core functionalities including Aggregate, Event Store, Aggregate Repository, Snapshot Store, and Dispatcher, to ensure optimum functionality and robustness. The testing guide will contain instructions on how to execute these tests. | +| **0d.** | Docker | We will deliver Dockerfiles for testing all the functionality included in this milestone. | +| 1. | Substrate module: Aggregate | The Aggregate pallet provides the base functionality for implementing the Command Query Responsibility Segregation (CQRS) pattern on a Substrate-based blockchain. It defines the Aggregate trait, which is used to define the state and behavior of an Aggregate. | +| 2. | Substrate module: AggregateState | The AggregateState pallet provides a default implementation of the AggregateState trait, which stores the current state of an Aggregate in the blockchain's storage. This pallet is responsible for managing the state of an Aggregate and updating it based on incoming commands. | +| 3. | Substrate module: AggregateRepository | The AggregateRepository pallet provides an implementation of the AggregateRepository trait, which is responsible for retrieving and storing Aggregates in the blockchain's storage. It allows developers to easily store and retrieve Aggregates from the blockchain's storage. | +| 4. | Substrate module: CommandDispatcher | The CommandDispatcher pallet provides a way to dispatch incoming commands to the appropriate Aggregates based on their type. It uses a HashMap to store the mapping between command types and the Aggregates that handle them. | +| 5. | Substrate module: EventStore | The EventStore pallet provides a way to store and retrieve events that have been emitted by Aggregates. It allows developers to easily retrieve the events emitted by a specific Aggregate and replay them to reconstruct the current state of the Aggregate. | +| 6. | Substrate module: EventsEmitter | The EventsEmitter pallet provides a way for Aggregates to emit events. It defines a trait that Aggregates can implement to specify the types of events they emit, and provides a way to subscribe to events emitted by specific Aggregates. | + + +### Milestone 2 — Testing and Documentation + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will ensure comprehensive documentation of the code by providing both inline comments and a step-by-step tutorial. This tutorial will guide the user through spinning up a Substrate-based execution environment for the CILA Omnichain Infrastructure and testing omnichain transactions, showcasing the new functionality. Special attention will be given to documenting the setup and testing of multiple Substrate chains running simultaneously, to test the synchronization of the state smart contract between them. | +| **0c.** | Testing and Testing Guide | We will conduct comprehensive unit testing on the core functionalities including Aggregate, Event Store, Aggregate Repository, Snapshot Store, and Dispatcher, to ensure optimum functionality and robustness. In particular, we will place emphasis on testing the infrastructure running with multiple chains to ensure that the synchronization mechanism is functioning as intended. The testing guide will contain instructions on how to execute these tests. | +| **0d.** | Docker | We will deliver Dockerfiles for testing all the functionality included in this milestone, including orchestration with multiple chains. For orchestration purposes we might use Kubernates. | +| 0e. | Article | We will publish a technical article that details the implementation of the Command-Query Responsibility Segregation (CQRS) and Event Sourcing architecture on the Substrate framework. The article will provide an in-depth explanation of the design choices made and the challenges faced during the implementation. It will also include a detailed walkthrough of the codebase, highlighting key areas of interest and how they fit into the overall architecture. The article will be written in a technical language that targets developers with experience in blockchain and distributed systems. | +| 1. | Substrate chain | Set up and run multiple Substrate chains simultaneously to test the synchronization of a state smart contract between them. This will involve deploying the omnichain smart contract infrastructure to each chain and executing transactions on each chain to ensure that the contract state is properly synchronized between them. Additionally, various network conditions such as network latency and node failures will be simulated to test the robustness and reliability of the synchronization mechanism. The results of these tests will be recorded and analyzed to identify any potential issues and ensure that the synchronization mechanism is functioning as intended. | +| 2. | Automated Tests | We will create and publish automated tests for critical infrastructure parts of Substrate-based CQRS + Event Sourcing execution enviroment. The aim of this test will be to test two cases - non conflicting execution (changes coming to one chain and transmitted to the other one), and conflicting transactions when the same aggregate is updated with two conflicing state changes that simuntaniusly come to different chans. | + +### Milestone 3 — Example Smart Contracts and Enhancements + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | Provide inline documentation of the NFTAggregate pallet and NFTAggregateState pallet code, as well as a basic tutorial that explains how a user can set up a Substrate node and send test transactions to test the NFT functionalities provided by these modules. Additionally, comprehensive unit tests will be developed and documented to ensure the functionality and robustness of the NFTAggregate pallet and NFTAggregateState pallet. A testing guide will also be provided, describing how to run the tests. | +| **0c.** | Testing and Testing Guide |For this milestone, we will develop comprehensive unit tests to cover the core functions of the NFTAggregate module and the NFTAggregateState pallet. These tests will be designed to ensure the functionality and robustness of the code. The unit tests will be included in the code repository and will cover a range of scenarios to ensure that the code is thoroughly tested. For example, we will test the minting, burning, and transferring of NFTs, as well as error handling and edge cases. In the testing guide, we will provide detailed instructions on how to run these tests, including any required dependencies and setup steps. We will also include information on how to interpret the test results and what to do in the case of failures or errors.. | +| **0d.** | Docker | In order to facilitate testing and deployment of the NFTAggregate pallet and NFTAggregateState pallet, we will provide Dockerfiles that can be used to easily set up and configure a development environment. These Dockerfiles will include all the necessary dependencies and configuration to run the Substrate-based blockchain with the new functionalities. | +| 1. | Substrate module: NFTAggregate | The NFTAggregate pallet provides a way to implement Non-Fungible Tokens (NFTs) on a Substrate-based blockchain. It defines a trait that NFT Aggregates can implement to specify the behavior of NFTs, including minting, burning, and transferring. | +| 2. | Substrate module: NFTAggregateState | The NFTAggregateState pallet provides a default implementation of the state of an NFT Aggregate, which stores the current state of NFTs in the blockchain's storage. This pallet is responsible for managing the state of NFTs and updating it based on incoming commands. | +| 3. | Report: Substrate Ecosystem NFT standards | To choose the most optimal standard for omnichain implementation we will conduct research and assess all the available NFT standards against two major criteria: popularity and technical quality. Popularity will be measured by the number of stars on the GitHub repository and how many projects are actually using it (usage assesment will be done on a best effort basis), and the technical quality will be assessed by analyzing if a specific standard satisfies [SOLID](https://en.wikipedia.org/wiki/SOLID) design principles. | + + +## Future Plans + +In the short term, we plan to continue to develop and enhance our project to ensure its success and sustainability. This will include ongoing testing, bug fixes, and implementing additional features and improvements as needed. We will actively promote our project through various channels, including social media, blog posts, and community events. + +After the completion of the proposed infrastructure, we intend to continue its development by incorporating support for multiple blockchains and introducing more advanced functionalities, such as dynamic rebalancing for aggregates. Additionally, we plan to establish partnerships with leading players in the Substrate/Polkadot/Kusama ecosystem and to integrate our omnichain infrastructure with existing projects, such as DeFi and NFT marketplaces, to further increase adoption. Finally, we will provide comprehensive documentation and support to ensure that our infrastructure is accessible and user-friendly for developers and users alike. + +In the long term, we envision our project becoming a leading platform for event-centric CQRS + Event Sourcing execution environments and omnichain smart contracts on the Substrate blockchain. We plan to expand our team and further invest in research and development to stay ahead of the curve and meet the needs of the rapidly evolving blockchain industry. We will continue to engage with the community and seek feedback to ensure that our project remains relevant and valuable to users. Our ultimate goal is to create a platform that is widely adopted and helps to drive the mainstream adoption of blockchain technology. + +## Additional Information :heavy_plus_sign: + +![mission](https://i.imgur.com/WZt1hdx.png) + +**How did you hear about the Grants Program?** personal recommendation diff --git a/applications/Calamar.md b/applications/Calamar.md new file mode 100644 index 00000000000..ff52a1eae69 --- /dev/null +++ b/applications/Calamar.md @@ -0,0 +1,282 @@ +# Calamar + +- **Team Name:** TopMonks +- **Payment Address:** 32NoFbB4x8bZ7YNvjra1DUYcje2B2XQwP3 (BTC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +This application is a response to a [Multi-chain Block Explorer](https://github.com/w3f/Grants-Program/blob/master/rfps/under_development/multi-chain-block-explorer.md) RFP + +### Overview + +Calamar is a block explorer for Polkadot and Kusama relay chains and their parachains, that uses Subsquid API for data fetching. + +The idea for another explorer has emerged during the dotsama events in Amsterdam and Prague. The team of TopMonks company's Blockchain Studio has gathered feedback from friendly projects such as HydraDx and KodaDot among others. +We have applied for and won the bounty from Subsquid in the Polkadot Hackaton: North America edition, that requested developing a block explorer. Our submission: https://devpost.com/software/calamar + +We call the app Calamar, as it is in line with the Subsquid identity. + +It is available here: +[https://calamar.app](https://calamar.app) \ +and we manage the code here: +[https://github.com/topmonks/calamar](https://github.com/topmonks/calamar) + +Based on the positive feedback we would like to push the project further and bring more valuable features for the users, closely cooperating with the [Subsquid](https://subsquid.io) team and gathering an ongoing feedback from the users. + +While developing Calamar, we focus on UI and UX friendliness so that users enjoy dotsama chains exploring, as well as relevance of displayed data. + +### Project Details + +Calamar explorer will allow users to search and display various items and statistics. + +The plan is to have at least these features implemented: + +#### Homepage +Homepage with google-like search box and with links to [chain dashboards](#chain-dashboards). + +![Home page](https://res.cloudinary.com/topmonks/image/upload/v1661767637/calamar/homepage.png) + +#### Universal search +Search where you don't have to know which chain the searched item belongs to. You just put the hash into the search box and the explorer will take care of the determining on which chain it is. This is going to be an addition to the ability to restrict search to a specific chain. + +#### Block detail +Display block's data and its extrinsics, transfers, calls and events. +- searchable by hash and height + +#### Extrinsic detail +Display extrinsic's data, its calls and events. +- searchable by hash and id + +#### Call detail +Display call's data, and its events. +- searchable by id + +#### Event detail +Display event's data +- searchable by id + +#### Search extrinsics and events by name +Display a list of matching extrinsics and events by name. +- full-text search - doesn't require exact name, substring is sufficient, case insensitive + +#### Account detail + +As we are gathering feedback, one of the most important features for the users seems to be the account overview where users can find information about their balances and transactions across all chains. + +- searchable by public key or chain-specific address +- display + - account's name if set + - owned assets accross all listed chains, including dollar values and graphs for visualization. + - list all chain-specific addresses + - list all related transfers, extrinsics and calls + +![Account page](https://res.cloudinary.com/topmonks/image/upload/v1672668761/calamar/account3.png) + +#### Chain dashboards + +Each chain will have own dashboard with statistics and listing of latest blocks, latest transfers, top holders, etc. It makes the explorer more useful even for users who are not searching for specific items. + +![Statistics page](https://res.cloudinary.com/topmonks/image/upload/v1697542484/calamar/statistics2.png) + +#### Metadata explorer + +The runtime metadata of each chain are still evolving and changing but it is not so easy to display them in a structured and human-readable way. There is e.g. a tool https://wiki.polkadot.network/docs/metadata which displays them but only latest version and supports only a few networks. The metadata explorer we are going to implement will support all the networks and also historical versions of the runtime spec. + +![Metadata explorer](https://res.cloudinary.com/topmonks/image/upload/v1672668761/calamar/metadata_explorer.png) + +#### Item metadata + +The metadata information will be deeply integrated into whole Calamar so we can display it in the detail pages of the items. E.g. in extrinsic's detail page we will show info for the call name, error, parameters and link to the metadata explorer for more info. + +![Extrinsic metadata](https://res.cloudinary.com/topmonks/image/upload/v1672668761/calamar/extrinsic_metadata.png) + +#### Search input autocomplete for call and event names + +Thanks to the metadata we can also autocomplete and suggest the call and event names when typing into the search input. + +### Technology stack + +Typescript, React, GraphQL + +### Ecosystem Fit + +- Calamar will help the community keep track of what's happening on the network, including XMC transfers, account overviews and chains statistics. +- Target audience are Dotsama developers, investors and ecosystem users. +- Calamar users will have opensource user-friendly UI prepared to use with Subsquid API. +- There are projects with similar functionality like Subscan or Polkaholic. Instead of trying to reinvent the wheel, we won't build our custom data indexing solution and rather rely on the powerful framework and API from Subsquid which is still evolving and has own dedicated development team. We focus on good UI and UX. Our solution will be aware of multichain environment (XCM transfers, cross-chain search, multichain account view). And the code will be opensource. + +## Team :busts_in_silhouette: + +### Team members + +- Antonina Nesmelova - developer +- Richard Jedlička - developer +- Radek Jakl - designer +- Jan Lopusek - project manager + +### Contact + +- **Contact Name:** Jan Lopusek +- **Contact Email:** jan.lopusek@topmonks.com +- **Website:** https://topmonks.com/ , https://blockchain.topmonks.com/ + +### Legal Structure + +- **Registered Address:** Struhařovská 2931/9, 141 00, Praha 4, Czech Republic +- **Registered Legal Entity:** TopMonks s.r.o + +### Team's experience + +All of our team members developed the first version of Calamar explorer. + +Antonina Nesmelova is young and enthusiastic web-developer with 3,5 years experience with web applications development, including a year and a half of experience in the world of crypto: development of dApps and smart contracts. + +Richard Jedlička has several years of expertise in web applications full-stack development. + +Radek Jakl invented the design for Calamar. He has many years of experience in graphics and UI/UX design. + +Jan Lopusek co-founded the startup studio for TopMonks software house. He is experienced project manager and business developer + +### Team Code Repos + +- https://github.com/topmonks +- https://github.com/topmonks/calamar +- https://github.com/uiii +- https://github.com/antonina-nesmelova + +### Project references + +- https://calamar.app/ +- https://about.meetvers.io/, https://app.meetvers.io/ +- https://brute.cz/ +- http://jaklradek.com/ + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/antonina-nesmelova-3a8365149 +- https://www.linkedin.com/in/richardjedlicka/ +- https://www.linkedin.com/in/jaklradek/ +- https://www.linkedin.com/in/jan-lopusek/ + +## Development Status :open_book: + +Current version of Calamar is running on https://calamar.app + +It is mostly a result of our participation in hackaton as an implementation of the bounty declared by Subsquid team. See [Additional Information](#additional-information-heavy_plus_sign). + +For now, it allows users to: +- search block by hash and height display its parameters and extrinsics +- search extrinsic by hash and display its parameters and events +- search account by address and list its extrinsics +- search extrinsics and events by their exact name. + +While it may seem to be already working explorer it has only basic features and lacks many of the important or useful ones. See [Milestone 1](#milestone-1--core-functionality) for details. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 11 weeks +- **Full-Time Equivalent (FTE):** 1 +- **Total Costs:** $27,500 + +### Milestone 1 — Core functionality + +- **Estimated duration:** 4 weeks +- **FTE:** 1 +- **Costs:** $10,000 + +Even though we have the already working application, there are still many things missing. Some of them prevent the users from using Calamar fully as the main explorer. We need to first assure the correct core functionality, display all the meaningful data which are retrievable without further complex processing, improve design and UX and integrate more into the Polkadot ecosystem. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide inline documentation of the code where necessary, technical description of how to run the own instance of Calamar and tutorials how to use the application from the user perspective. | +| 0c. | Testing Guide | We will provide end-to-end tests covering UI functionality. | +| 0d. | Docker | We will provide a Dockerfile(s) for testing and running own Calamar instance. | +| 0e. | Article | We will publish an article that explains what was done as part of the grant. | +| 1. | Fix usage blockers | Fix things which block the app's real usage
  • search results are not shareable due to missing info about the chain in the URL
  • extrinsic's args are missing
| +| 2. | Add related items listings | Add missing related items listing to detail pages
  • block's extrinsics, call and events
  • extrinsic's calls
+| 3. | Add call detail page | See [Call detail](#call-detail). | +| 4. | Add event detail page | See [Event detail](#event-detail). | +| 5. | Responsiveness | Improve overall responsiveness for mobile devices especially of item tables and extrinsics/event args. | +| 6. | Extrinsics/event args displaying improvements | Add args display options: raw/json, human readable. Find a better way to show nested properties' data types. | +| 7. | Items count | Current implementation doens't show the total number of searched items. We would like to retrieve the items count and display it properly. | +| 8. | Extrinsic/event case-insensitive search by name | Add ability to search extrinsics and events by their name case-insensitive. | +| 9. | Account address parsing in events args | Detect account address in event args and link it to the account detail (chain detected automatically). | +| 10. | Website polishing | Add useful information to the website (footer with team logos, contact information, terms, etc.). | +| 11. | Polkadot.js integration | Create a PR to integrate links to the Calamar Explorer into Polkadot.js app. | + +### Milestone 2 - Account detail & Chain dashboards + +- **Estimated duration:** 4 weeks +- **FTE:** 1 +- **Costs:** $10,000 + +In this milestone we are going to improve [account detail](#account-detail) page and replace latest extrinsics page with proper [dashboard](#chain-dashboards) page for each chain. + +*Subsquid (data provider) might not support each feature for all chains at the time of the implementation, so the features will be implemented universally to support each chain whenever the data are provided in the future.* + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide inline documentation of the code where necessary and user documentation for new features. | +| 0c. | Testing Guide | We will provide end-to-end tests covering UI functionality. | +| 0d. | Docker | *N/A - will be provided by the first milestone.* | +| 0e. | Article | We will publish an article that explains what was done as part of the grant | +| 1. | Account / Balance overview | Overview of owned assets accross all listed chains with chain specific addresses, including dollar values | +| 2. | Account / Balance charts | Chart visualization of balance by assets and by type (reserved, tranferable, ...), including dollar values | +| 3. | Account / Transfers list | Add account's transfers list table | +| 4. | Account / Calls list | Add account's calls list table | +| 5. | Account / Identity info | Add account's identity information if set (name, twitter, ...) | +| 6. | Chain dashboard / Stats | Show chain's stats (blocks count, signed extrinsics count, total issuence, transfers count, holders count, total issuence, staked value, inflation rate, validators count) including USD values | +| 7. | Chain dashboard / Asset value chart | Chart visualization of asset value by type (staked, circulating, other) | +| 8. | Chain dashboard / Latest blocks | Add latest blocks list table | +| 9. | Chain dashboard / Latest transfers | Add latest transfers list table | +| 10. | Chain dashboard / Top holders | Add top holders list table | + + +### Milestone 3 - Universal search & Metadata explorer + +- **Estimated duration:** 8 weeks +- **FTE:** 0.375 +- **Costs:** $7,500 + +In this milestone we are going to implement [universal search](#universal-search) and one of the most requested features: [cross-chain transfers](#cross-chain-transfers) detection. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide inline documentation of the code where necessary and tutorials on how to use new features. | +| 0c. | Testing Guide | We will provide end-to-end tests covering UI functionality. | +| 0d. | Docker | *N/A - will be provided by the first milestone.* | +| 0e. | Article | We will publish an article that explains what was done as part of the grant | +| 1. | Universal search | Search items through all the chains without the knowledge where it belongs. See [Universal search](#universal-search). | +| 2. | Metadata explorer | UI interface for exploring metadata retrieved from network's latest and historical versions of runtime spec. See [Metadata explorer](#metadata-explorer). +| 3. | Show related runtime metadata in items' detail | Show related metadata information directly in detail pages of individual items and interlink to metadata explorer. See [Item metadata](#item-metadata). +| 4. | Search input autocomplete | Autocomplete extrinsic and event name in the search input. See [Search input autocomplete for call and event names](#search-input-autocomplete-for-call-and-event-names). + +## Future Plans + +There is a huge potential for future improvements which the Polkadot's community can benefit from. + +We would like to definitely display information about XCM transfers and teleports. + +As developers of most parachains implement their own custom modules/pallets it opens the opportunity to cooperate and customize Calamar explorer with UI/UX components and logic tailored to their needs. + +It relates to various XCM transactions which makes it even more complex and the more types will our explorer support the more it makes the users' lives easier. + +Another requests which came to us are: +- supporting EVM and WASM smart contracts +- exporting transactions for accounting and taxation purposes +- displaying NFTs collections and crowdloans rich data + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Personal recommendation + +- We participated and won a bounty in [Polkadot Hackaton: North America Edition](https://polkadot-na.devpost.com/) + - bounty: https://github.com/subsquid/bounties/issues/1 + - our submission: https://devpost.com/software/calamar +- We are cooperating with [Subsquid team](https://subsquid.io) that provides us data diff --git a/applications/Cere_Turnkey_Private_Blockchain_Network.md b/applications/Cere_Turnkey_Private_Blockchain_Network.md index 06ada64d3a4..ecfed31b2ff 100644 --- a/applications/Cere_Turnkey_Private_Blockchain_Network.md +++ b/applications/Cere_Turnkey_Private_Blockchain_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Turn-key Private Standalone Blockchain Network -* **Project:** Turn-key Private Standalone Blockchain Network * **Proposer:** [Cere-Network](https://github.com/Cerebellum-Network) * **Payment Address:** 1BbyAGddobdPgNo9c63xsRnwK5hen8pV7F diff --git a/applications/Claps.md b/applications/Claps.md new file mode 100644 index 00000000000..200d8c0b6b8 --- /dev/null +++ b/applications/Claps.md @@ -0,0 +1,284 @@ +# Claps Health + +- **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 + +### Make self-care a fun game with Claps +Claps is the mobile app that integrates gaming with personal health tracking can be a fun and engaging way to encourage users to track their health on a daily basis and make healthy lifestyle choices. The app could allow users to play games and record the results as a health diary, and reward them with incentives and rewards for completing diagnostic tests or answering questionnaires such as mood tracking. + +Claps defines itself as a "gamified health tracking app" that uses gaming elements to motivate users to track their health and make healthy lifestyle choices. By integrating with artificial intelligence (AI) into a gamified health tracking app to provide a more personalized and interactive user experience. + +The Claps AI is designed to support health practitioners in tracking patients' data on a daily basis. The AI algorithms analyze patients' health information and provide insights and recommendations to assist health practitioners in delivering personalized care to their patients. This can improve patient outcomes and help practitioners provide the most effective and efficient care. + +Claps is designed to be engaging and enjoyable to use, and could provide users with feedback and support to help them achieve their health goals. It could be a useful tool for promoting health and well-being, and could be particularly appealing to users who enjoy gaming and are looking for a more interactive and engaging way to track their health. + +By using Substrate technology to store and manage data, facilitate data sharing, dapps contracts, and create and manage digital assets such as NFT with patient’s data. In the long-term, patients could potentially benefit from blockchain including in the areas of insurance and financial support. By leveraging the transparency, security, and efficiency of blockchain technology, patients could be better equipped to access the care and support they need. + +Taiwan Research-based Biopharmaceutical Manufacturers Association (TRPMA) is jointly established by 28 biopharmaceutical manufacturers and developers and 19 regenerative medicine companies based in Taiwan. This proposal is proposed by Jacob Lee, director of the digital health team at TRPMA. Jacob Lee is the co-designer of phrOS(Personal Health Records Operating System), a Ethereum private blockchain and IPFS Cluster based SaaS at Medical Center Hospital in 2017. + +## Project Details + +### Architecture +![claps_health_diagam](https://user-images.githubusercontent.com/14127551/218294412-3f0c2a9e-774a-49f0-b4c0-67e8ee6cb896.png) + +## Claps App Use Case + +### Patients + +Use the app to track their mood on a daily basis +Receive rewards by reporting their mood or blood pressure, or by completing other activities such as questionnaires. By providing these proof of work to the Claps dapps(Claps DAO). +View personalized health education content provided by health practitioners +Share their mood tracking data with their healthcare provider for review and analysis + +### Pharmaceutical Company + +Use the data collected by the app to inform their product development and marketing strategies +Provide funding to health practitioners to produce health education content for the app +Use the app as a platform to promote their products and services to patients + +### Health Practitioners + +Use the app to provide personalized health education content to patients +Use the data collected by the app to inform treatment decisions and track patient progress +Receive funding from pharmaceutical companies to produce health education content for the app + +### AI Assistant + +Collect and analyze data from patients' mood tracking +Provide personalized recommendations and education content to patients based on their data +Facilitate communication and collaboration between patients, health practitioners, and pharmaceutical companies. + +## Solutions +### Gamefield Mood Tracking + +By gamifying the experience through a health diary design, aims to break through the challenge of collecting mental health real-world data. The app provides a challenge card and a way for users to set personal goals, track progress, and receive rewards for their efforts. This approach makes the experience more engaging, encouraging patients to stick with their tracking habits and provide more accurate data. The personal goal-setting feature also caters to a wide range of needs and preferences, making the app more accessible and appealing to a broad audience. + +### Health Practitioners AI Assistant + +AI can help health practitioners in various ways by analyzing patient data and providing actionable insights to improve patient care. The use of AI can save time and improve the efficiency of health practitioners by automating routine tasks and allowing them to focus on more complex and critical tasks. AI-powered alerts can help practitioners detect potential issues earlier and provide more proactive care. By providing tailored recommendations based on individual patient data, AI can also help practitioners make more informed decisions and provide personalized care. + +### Omni-channel + +This allows pharmaceutical companies to track and analyze the behavior and engagement of healthcare practitioners, patients, and other stakeholders, and make data-driven decisions about their marketing and communication strategies. These solutions can help pharmaceutical companies to make data-driven decisions about their marketing and communication strategies, which can help improve patient outcomes and the quality of care. + +### Web3 Technology + +Web3 technologies can give individuals more control over their personal health records, as they can choose who has access to their data and when it is shared. This can help to enhance privacy and ensure that personal health information is used appropriately. + + +## Our Goals +Improve the quality of care and outcomes for patients. + +- Chronic disease awareness and prevention +- Maternal and infant health +- Mental and behavioral health +- Nutrition, exercise and obesity prevention +- Alcohol, tobacco use and substance abuse + +Claps enable patients to self-report, self-test, and access health education, and that incorporate AI-based features, can be a useful tool for improving the quality of care and outcomes for patients. By providing patients with the tools and support they need to manage their own health, these apps can help to empower patients and to improve the effectiveness of healthcare delivery. + +## Technology + +### Substrate Blockchain + +By using Substrate blockchain technology to store and manage data, facilitate data sharing, dapps contracts, and create and manage digital assets with patient’s data. Leveraging Substrate blockchain technology for healthcare can offer significant benefits for patients and healthcare industry, providing them with enhanced privacy protection and better data consent management. By taking control of their own data, patients can access the care and support they need more efficiently and securely. + +### Self-Sovereign Identity (SSI) + +Self-Sovereign Identity (SSI) is a decentralized digital identity model that puts individuals in control of their personal information and how it is used. This approach to identity provides users with more privacy and control over their personal information, and helps to prevent data breaches and misuse of sensitive information. + +### Zero-knowledge proof + +The zero-knowledge proof is part of SSI, this means that a user can prove their identity or access rights to a service without revealing any sensitive personal information. This helps to protect the privacy of the user and reduce the risk of data breaches, while still enabling secure and reliable authentication. +![zkproof](https://user-images.githubusercontent.com/14127551/218294803-fefcbb47-9be2-418a-a595-424302e838bb.png) + +### GPT-3 AI model + +GPT-3 (Generative Pre-trained Transformer 3) is a state-of-the-art language processing artificial intelligence developed by OpenAI. The GPT-3 chatbots are designed to interact with patients on a daily basis to support and enhance the continued care work of health practitioners. It's always monitored by health practitioners to ensure the accuracy and relevance of their responses. + +## Ecosystem Fit + +The pharmaceutical companies in this ecosystem can provide information to doctors, doctors provide consultation and health education to patients, and patients provide self-health tracking to doctors, could potentially be an effective way to improve the quality and accessibility of healthcare. In this model, the pharmaceutical company would be responsible for providing relevant and accurate information to doctors, who would then use this information to provide consultation and health education to patients. Patients would be responsible for tracking their own health and providing this information to doctors, which could help to inform treatment and care decisions. + +## Team :busts_in_silhouette: + +### Team members + +- Jacob Lee, Team Lead +- Brady Liu, Project Tech Lead +- Dr. Nicky Liu, Project Manager +- Carol Cheng, Regulation and compliance + +### Contact + +- **Contact Name:** Jacob Lee +- **Contact Email:** jacoblee@dtco.co +- **Website:** https://trpma.org.tw/ + +### Legal Structure + +- **Registered Address:** 1F, No 465-1, Sec. 6, Chung-hsiao E. Rd., Nan-kang Dist., Taipei City 11557, ROC TAIWAN + +- **Registered Legal Entity:** TAIWAN RESEARCH-BASED BIOPHARMACEUTICAL MANUFACTURERS ASSOCIATION + +### Team's experience + +Taiwan Research-based Biopharmaceutical Manufacturers Association (TRPMA) is jointly established by 28 biopharmaceutical manufacturers and developers and 19 regenerative medicine companies based in Taiwan. This proposal is proposed by Jacob Lee, director of the digital health team at TRPMA. Jacob Lee is the co-designer of phrOS(Personal Health Records Operating System), a Ethereum private blockchain and IPFS Cluster based SaaS at Medical Center Hospital in 2017. The Digital Health Team at TRPMA has also supported the Taiwan government by developing a regenerative medicine management system from 2020-2023, and actively working on a Covid-19 project with a Dublin study team since 2021. + +### Team Code Repos + +Claps Health +https://github.com/Claps-Health/ + + +- https://github.com/jacobleegithub/ +- https://github.com/bradyliu-dtco/ + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/jacob-lee-aa435916/ +- https://www.linkedin.com/in/brady-liu-734a27106/ +- https://www.linkedin.com/in/nicky-lu-449b02131/ + + +## Development Status :open_book: +New project + +## Development Roadmap :nut_and_bolt: + +### Amendment - Timeline Extension (Sep, 18 2023) + +Due to unforeseen challenges and to ensure the quality of our deliverables, we are proposing an extension to the project timeline. + +Original Estimated End Date: *End of the 4.5 months from April 2023* +Revised Estimated End Date: **December 2023** + +**Reasons for Extension:** +- *Thank you for supporting Claps Health and granting us the opportunity to bring this vision to life. Since initiating the project in April 2023 (approved by middle of March), we've faced unforeseen challenges in the Rust and Substrate Technology learning curve. While we've onboarded experienced Substrate professionals to address this, the Item 3 related to zk-proof still to be develop.* + +- *Milestone 1: Patient Identity and Security Framework +Status: Delayed due to zk-proof +Estimated Completion Date: Oct 30, 2023* +- *Milestone 2: Patient Engagement and Data Sharing +Status: Delayed due to Milestone 1 +Estimated Completion Date: Dec 30, 2023* + +**Technical Specification amendment:** +- *Patient ID creation - Develop the patient ID creation tool in Javascript. Changed to Develop the patient ID creation tool in Dart.* +- *Patient ID on-chain authentication - zkSNARKs Groth16 based on Non-Interactive Zero-Knowledge Proof (NIZKP) developed by !ink Smart Contract. Changed to Patient ID on-chain authentication - zkSNARKs Groth16 based on Non-Interactive Zero-Knowledge Proof (NIZKP) developed by xcm, runtime module or !ink smart contract.* + +We assure the committee that despite the delay, the quality and scope of the project will remain consistent with our initial proposal. + +### Overview + +- **Total Estimated Duration:** 8 months (Adjusted from 4.5 months) +- **Full-Time Equivalent (FTE):** 4 FTE +- **Total Costs:** 30,000 USD + +### Milestone 1 - Patient Identity and Security Framework + +- **Estimated Duration:** 6 months (Adjusted from 2.5 months) +- **Developers:** FTE x 4 +- **(Product Design x 1, Dapp Engineer x 1, System Engineer x 1, App Engineer x 1)** +- **Costs:** 20,000 USD + +| Number | Deliverable | Specification | +| ------ | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will post an article on Twitter and Meta(Facebook) for English and Mandarin speakers communities. | +| 1 | Patient ID creation | \- Develop the patient ID creation tool in Dart.
\- Generate a new ID on client-side for the patient based on BIP39. (12 words passphrase)
\- Encrypted key store(private key) by patient user’s password (AES-256 GCM mode)
\- Implement the decentralized design using public key cryptography. (Client signed by private key) | +| 2 | Patient profile management module | \- Patient profile off-chain management tools developed by JAVA
\- Support AWS S3 storage
\- Updating of patient profile
\- ECIES end-to-end data encryption to secure profile data transfer. | +| 3 | Patient ID on-chain authentication | \- zkSNARKs Groth16 based on Non-Interactive Zero-Knowledge Proof (NIZKP) developed by xcm or runtime module or !ink Smart Contract
\- Receive credential by trust issuer (token file)
\- Zero-knowledge proof for on-chain authentication to prove patient ID without private information | +| 4 | Challenge card dapp module | Provide a way for users to set personal goals, track their progress, and receive rewards for their efforts. Dapp developed in ink! smart contract.

\- Add challenge card
\- Add personalized mission
\- Delete challenge card
\- Receive daily mission
\- Receive rewards by mission completed
\- Receive rewards by challenge completed
\- Rewards by fungible tokens | +| 5 | Create database | Create a docker container to start a mySQL database to store all the information, define the models to store and create tables and indexes. | +| 6 | Database encryption module | We will implement a database encryption AES-256 GCM module of all stored and transmitted data to prevent unauthorized access or tampering. Developed by JAVA. | +| 7 | Android apk | We will provide android apk for above challenge card data input and functional verification
We will provide android apk for user challenge card with wallet to receive rewards | +| 8 | Testing | Achieve a testing coverage of the functionalities above 90% | + +### Milestone 2 - Patient Engagement and Data Sharing +- **Estimated Duration:** 2 month +- **Developers:** FTE x 4 +- **(Product Design x 1, Dapp Engineer x 1, System Engineer x 1, APP Engineer x 1)** +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| ------ | ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an article/workshop video that explains how Claps Health Benefits to patients and healthcare business. Patients are the end-users of Claps Health application, so it's important to explain how Claps Health will benefit them. The article/video will cover topics such as how the app helps patients manage their health, how it improves access to healthcare, and how it ensures data privacy and security. Article/Workshop will be in English and Mandarin. | +| 1. | Claps Health Data Sharing protocol: Consent management | We will implement a health data sharing protocol based on dapp to enable secure sharing of health data among various stakeholders. Developed by !ink Smart Contract.
\- Accept consent
\- Revoke consent
\- View data sharing requests

a. The consent data will be stored anonymously, without any personal identifying information.
b. The smart contract will be accessible to authorized parties using public key cryptography.
c. Users are able to request that their data be permanently deleted from the system at any time (Please reference Data privacy control module)
d. Users are able to see a list of all the organizations that have requested access to their data, along with the specific types of data being requested, and be able to manage these requests. | +| 2. | Claps Health Data Sharing protocol: Patient data feed | We will implement a health data feed on the backend, developed using Java.
\- Subscribe data feed by numbers of Patient ID
\- Unsubscribe data feed by Patient ID

a. The data feed will allow authorized parties to access and subscribe to a patient's health data in real-time.
b. The data will be encrypted using ECIES to ensure data security.
c. The data feed will be accessible through a secure API, which will authenticate and authorize users using public key cryptography.
d. Support delete data by patient required. | +| 3. | Data privacy control module | We will implement a data privacy control module to allow patients to exercise their rights under the GDPR, delete their personal data by patient’s requirement. Developed by JAVA. | +| 4. | Audit logging on web backend | The web backend will implement an auditable log of all access to the system, including who accessed it and what actions were performed, to help detect and respond to security incidents. Developed by JAVA. | +| 5. | Support for Mandarin speakers community | Translate the app to Mandarin and add support to switch languages | +| 6. | Testing | Add tests to the components. Achieve a testing coverage of the functionalities above 90% | +| 7. | Final setups | Deal with all production issues/configuration requirements such as creating the final docker image, reviewing the documentation and verifying everything works fine. | +| 8. | Deploy the app | Define the final domain (Claps.health) and deploy the app | + +## User Interface + +The user interface will be based on [here](https://www.figma.com/file/Zlx3Qq4EoFtuV8AopAffVl/Claps-Health-Mobile-for-Patients?node-id=0%3A1&t=pUNA27WItIqVx5n8-1) + +![app01](https://user-images.githubusercontent.com/14127551/223708073-28ffd406-a286-4f80-9476-c728762f6812.png) + +p.s. The gray area will be for future development, such as health education services. +The web backend for pharmaceutical and healthcare service providers, including omni-channel and health data analytics, will also be a focus of our future development. + +## Regulation and Compliance with HIPAA/GDPR + +### Pseudonymization + +By using pseudonyms, the health data can be processed and shared in a secure and de-identified manner, while still allowing for verifiable identification. + +### End-to-end data encryption +Claps Health offers tools based on public key cryptography ECIES encryption to secure data storage and transfer are compliance with patient data protection and industry requirements. Only authorized parties can access the data. The application layers are using AWS S3 industry compliance secure storage. + +### Database data encryption +Claps Health backend database using AES256 GCM data encryption to secure database data. Based on data access policy, only authorized parties can access the data. The application layers are using AWS S3 industry compliance secure storage. + + +### Audit logs + +The auditable log of all access to the system, including who accessed it and what actions were performed +Consent Tracking + +By implementing consent tracking smart contracts, organizations can demonstrate that they are following privacy regulations and that patients have control over their health data. + +### Right to be forgotten + +Claps Health does not store personal data on the blockchain and there is only random ID and hash code on chain. Individuals have more control over their data and can request deletion of the corresponding data in the database. Ensure that all personal data is securely deleted and no residual information remains that could be used to re-identify individuals. + +However, it is important to note that HIPAA/GDPR compliance involves a comprehensive set of rules and regulations for protecting health information. This proposal does not cover all of the guidelines such as physical access, governance of organizations..etc. + +## Future Plans + +## Health Educations + +We are planning to expand Claps Health by developing a health education publishing service. This service will be available on our web backend and mobile app, and will allow healthcare providers to create and share educational content with their patients. By providing easy access to reliable health information, we hope to empower patients to take control of their health and wellbeing. + +## Omni-Channel and Health data analytics + +We recognize that healthcare providers need a way to analyze large datasets to identify patterns in health behaviors and improve patient outcomes. To meet this need, we are planning to develop an omni-channel health data analytics service on our web backend. Based on patient Informed Consent Management + +### Open AI Integration + +We are planning to integrate Open AI into Claps health mobile app in a second phase, after testing the market and gathering feedback. This approach allows us to minimize development costs and time in the first phase, while also gathering feedback and making sure that the features that we implement in the second phase are the most useful and needed. + +### Expand Substrate + +We are planning to build an omnichannel platform for pharmaceutical companies and healthcare related based on Polkadot Substrate for expanding the ecosystem, providing a more secure and private way of data management, better interoperability, automation and improved healthcare education communication. + +### Additional Information + +Reference: +https://www.ledgerinsights.com/blockchain-health-records-taiwan/ +https://medium.com/dtco/blockchain-enabled-personal-health-record-os-challenges-opportunities-in-health-care-55161e3a5a32 diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests.md b/applications/CoinFabrik_On_Ink_Integration_Tests.md new file mode 100644 index 00000000000..df2ba2e1c0d --- /dev/null +++ b/applications/CoinFabrik_On_Ink_Integration_Tests.md @@ -0,0 +1,158 @@ +# CoinFabrik On Ink Integration Tests +- **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 + +CoinFabrik has successfully accomplished two previous grant milestones for the development of [Scout](https://coinfabrik.github.io/scout/), an open source bug-detection tool for ink! targetted to developers and smart contract auditors. + +We have completed a [Proof of Concept](https://github.com/CoinFabrik/web3-grant ) and a [Prototype](https://github.com/CoinFabrik/scout ). + +During these iterations, we encountered certain challenges, especially while developing fuzzing detectors. These challenges included limitations in integration tests and differences with the ink! E2E testing environment. Specifically, we faced difficulties when working with functions in integration testing related to cross contract calls, storage, gas usage, and delegatecall. + +With this grant, our objective is to conduct a comprehensive analysis to identify any other missing functionalities in integration tests, and to propose and develop new testing features based on our findings. + +Our intention is to `flatten the anvil` of ink! integration testing. With a properly flattened anvil, quality tools can be built. + +### Project Details + +As mentioned before, we have already identified a number of E2E functionalities that are not present in integration tests. + +For example: +- A different implementation of storage in integration testing vs E2E testing. The same storage limitations present in E2E should also be present in integration testing. +- Inability to perform delegatecall in integration tests. +- Inability to perform cross contract calls in integration tests. +- Gas consumption is not integrated. +- Address inconsistencies. Alice and Bob addresses differ between integration and E2E tests environments. + +This list is not exhaustive, as it simply highlights some difficulties we encountered while conducting integration tests for vulnerability examples during the development of detectors for our static analyzer, [Scout](https://github.com/CoinFabrik/scout). + +The overall advantage of integration tests is that, since they are performed off-chain, they are significantly faster than E2E tests, which imply compiling and deploying the smart contract to a Substrate node. We believe that having a complete set of functionalities for integration tests will allow developers to thoroughly test their code more quickly. Particularly, we believe the impossibility to perform cross contract calls in integration tests is a limitation for developers trying to quickly assess interactions across different contracts. This can be done through E2E tests, but it takes more time. + +Our proposal is to begin our work by making a full review of the current functionalities of integration tests and E2E tests. From this revision, we will assemble a comparative table, identifying differences and proposing improvements and missing developments to be made for integration tests. For specific cases where the enhancement or missing functionality is clear, and the implementation of the enhancement is deemed feasible, code examples could be provided to show the current limitations of integration tests. + +Furthermore, we need to thoroughly analyze the complexity and feasibility of generating the necessary tests. The analysis we just mentioned will allow us to better understand which improvements will truly be possible to develop. This includes listing the missing functionalities in integration tests that are available for E2E testing, analyzing the feasibility of their implementation, and prioritizing their development order. + + + +### 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. + +In the context of fuzzing detectors, integration tests are useful during their development in order to identify fuzzing parameters, 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 fuzzing detectors for ink! smart contracts (e.g: [Fuzzland](https://github.com/w3f/Grants-Program/blob/master/applications/FuzzLand.md) team developing [Ityfuzz](https://github.com/fuzzland/ityfuzz), [Klevoya](https://github.com/w3f/Grants-Program/blob/master/applications/klevoya_fuzzer.md ) team). + +## Team :busts_in_silhouette: + +### Team members + +- Ariel Wassbein, Head of Research. +- Diego Kelyacoubian, Head of Program Management. +- Valeria Caracciolo, Business Development. +- CoinFabrik's development and auditing team. + + +### 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/scout +- https://github.com/CoinFabrik/web3-grant + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/arielwaissbein/ +- https://www.linkedin.com/in/diego-kelyacoubian-5417613/ +- https://www.linkedin.com/in/valeriacaracciolo/ + + +## Development Status :open_book: + +We have already identified some improvements to be made in integration tests. We also identified how they are implemented in E2E tests and provide an initial level of complexity / feasibility associated to their development: + +| Issue Number | Issue Name | Description | Feasibility | References | +|--------------|------------|-------------|-------------|------------| +| 1 | Alice and Bob's addresses | Alice and Bob's addresses should match across integration and E2E tests. | Feasible | Accounts on Integration Tests: [Link](https://github.com/paritytech/ink/blob/c2af39883aab48c71dc09dac5d06583f2e84dc54/crates/env/src/engine/off_chain/test_api.rs#L333)
Accounts on E2E tests: Addresses are used from this library [Link](https://github.com/paritytech/substrate/blob/28e906dffcaa91e85f59aff628d953ebeb036ae2/primitives/keyring/src/sr25519.rs#L108C38-L108C38)
Account addresses are different for both Alice and Bob. | +| 2 | Storage Limitations | The storage in the integration environment should have the same limitations as in the blockchain environment (end-to-end). | Feasible | Set_contract_storage is implemented differently in integration tests vs E2E tests.
In integration tests, set_contract_storage is implemented this way: [Link](https://github.com/paritytech/ink/blob/c2af39883aab48c71dc09dac5d06583f2e84dc54/crates/env/src/engine/off_chain/impls.rs#L185)
In E2E tests, the implementation calls the ext::set_storage function, this function is implemented in a way that checks maximum value lengths: [Link1](https://github.com/paritytech/ink/blob/c2af39883aab48c71dc09dac5d06583f2e84dc54/crates/env/src/engine/on_chain/impls.rs#L215) [Link2](https://github.com/paritytech/substrate/blob/28e906dffcaa91e85f59aff628d953ebeb036ae2/frame/contracts/src/wasm/runtime.rs#L790)
The checking of maximum value lengths through the ext::set_storage function is not implemented in integration tests. | +| 3 | Delegate call | Ability to use delegate calls in integration tests. | Complex, yet feasible. | Not implemented in integration tests: [Link](https://github.com/paritytech/ink/blob/c2af39883aab48c71dc09dac5d06583f2e84dc54/crates/env/src/engine/off_chain/impls.rs#L449)
Notice in line 460: “off-chain environment does not support delegated contract invocation"
In E2E tests, it is implemented here: [Link](https://github.com/paritytech/substrate/blob/28e906dffcaa91e85f59aff628d953ebeb036ae2/frame/contracts/src/wasm/runtime.rs#L1467) | +| 4 | Cross contract calls | Ability to perform contract-to-contract calls during integration tests. | To be evaluated. | Not implemented in integration tests: [Link](https://github.com/paritytech/ink/blob/c2af39883aab48c71dc09dac5d06583f2e84dc54/crates/env/src/engine/off_chain/impls.rs#L432)
Notice in line 446: “off-chain environment does not support contract invocation"
In E2E tests, it is implemented here: [Link](https://github.com/paritytech/substrate/blob/28e906dffcaa91e85f59aff628d953ebeb036ae2/frame/contracts/src/wasm/runtime.rs#L1412) | +| 5 | Gas usage | Gas usage in the integration environment should have the same limitations as in the blockchain environment (end-to-end). | To be evaluated. | Not implemented in integration tests: [Link](https://github.com/paritytech/ink/blob/c2af39883aab48c71dc09dac5d06583f2e84dc54/crates/engine/src/ext.rs#L404)
Notice in line 405: “off-chain environment does not yet support gas_left"
In E2E tests, it is implemented here: [Link](https://github.com/paritytech/substrate/blob/28e906dffcaa91e85f59aff628d953ebeb036ae2/frame/contracts/src/wasm/runtime.rs#L1974) | + +We validated the idea of the analysis and development described in this application with Sam Ruberti from the ink! Ecosystem and David Hawig from Web3 Foundation, who encouraged us to apply for this grant. + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 weeks +- **Full-Time Equivalent (FTE):** 2.5 FTE +(0.25 Project Manager, +0.25 Tech Lead, +1 Full time Sr. Rust Developer, +1 Full Time SemiSr. Rust Developer) +- **Total Costs:** 13,500 USD + + +### Milestone 1: Analysis +- **Estimated duration:** 2 weeks +- **FTE:** 2.5 +- **Costs:** 13,500 USD + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | Create a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. The report's focus is to identify what can be accomplished in E2E tests but not currently in integration tests, as well as any inconsistencies. If applicable, we will provide suggestions that are not covered by either test type. +| 0c. | Testing and Testing Guide | No tests will be produced at this stage. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will prepare a summary report and publish it on our blog https://blog.coinfabrik.com/ + **1** | Analyze | Study and compare Integration and E2E (End-to-End) tests in ink!. + **2** | Evaluate | Assign a complexity level to each finding based on the difficulty of implementing the missing or enhanced functionality. + **3** | Estimate | Indicate an order of priority under which the missing functionalities shall be developed during the next milestone, where the functionalities are effectively implemented for integration tests. + + +## Future Plans + +After finishing Milestone 1: Analysis, and having a good understanding of which missing functionalities in the integration testing environment can be developed, as well as an estimation of the effort required to develop them, we will submit a new grant proposal for a second milestone. The intention of this second milestone is to effectively implement these missing features. We detail in the table bellow its deliverables; its estimated duration is to be defined upon the delivery of the initial Analysis milestone. + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will update our previous report. This includes the current status of identified use cases. +| 0c. | Testing and Testing Guide | We will develop the missing functionalities identified, and submit a pull request to the corresponding repository. The newly developed functionalities will be documented and a testing guide will be included. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will publish an updated report in our blog at https://blog.coinfabrik.com/. + **1** | Develop | Build the necessary improvements and missing tests for the identified use cases outlined in the first milestone. + **2** | Analyze and Estimate | If applicable, suggest additional tests for this or next milestones. + +Moving forward, we have two projects in mind: +1. Research and develop an advanced testing automation solution for ink! smart contracts. +2. Improve our open source bug-detection tool [Scout](https://coinfabrik.github.io/scout/) +## Referral Program (optional) :moneybag: + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result. + +During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation. + diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests_2.md b/applications/CoinFabrik_On_Ink_Integration_Tests_2.md new file mode 100644 index 00000000000..684228a91ea --- /dev/null +++ b/applications/CoinFabrik_On_Ink_Integration_Tests_2.md @@ -0,0 +1,182 @@ +# CoinFabrik On Ink Integration Tests 2 +- **Team Name:** CoinFabrik (Nektra S.A) +- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +We have discovered that integration tests for ink! contracts lack some of the functionalities, or present implementation differences, when compared to E2E testing. + +Integration tests run significantly faster than E2E (end-to-end) tests. If a full range of functionalities were provided, it could reduce testing and QA times. + +Our intention is to `flatten the anvil` of ink! integration testing. With a properly flattened anvil, quality tools can be built. + + +### Project Details + +We have conducted a comprehensive analysis to identify any missing functionalities in integration tests and implementation differences with E2E tests, and to propose and develop new testing features based on our findings. This analysis was carried as part of a previous grant ([link](https://github.com/w3f/Grant-Milestone-Delivery/pull/998)). + +With this new grant, our objective is to implement our findings. Specifically, we aim to address functions in integration testing that have missing implementations or show differences when compared to e2e tests. We will add our contributions into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). + +### Ecosystem Fit + +Having a comprehensive set of functionalities available for integration tests would bring numerous benefits to the entire community, including improved reliability, code quality and maturity, and faster feedback loops. + +Integration tests are useful during their development and they are quicker than E2E tests. We learned this while working on fuzzing detection techniques during the [Proof of Concept of Scout](https://github.com/CoinFabrik/web3-grant), which we performed in collaboration with [researchers from the University of Buenos Aires](https://lafhis.dc.uba.ar/home). We believe that having a complete set of functionalities for integration tests would be useful for other teams working in the development of ink! smart contracts. + +## Team :busts_in_silhouette: + +### Team members + +- Ariel Wassbein, Head of Research. +- Agustin Aon, Technical Lead. +- Valeria Caracciolo, Business Development. +- CoinFabrik's development and QA teams. + +### Contact + +- **Contact Name:** Valeria Caracciolo +- **Contact Email:** valeria.caracciolo@coinfabrik.com +- **Website:** https://www.coinfabrik.com/ + +### Legal Structure + +- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina. +- **Registered Legal Entity:** Nektra S.A. + +### Team's experience + +We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 200 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL. + +Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires. + +As well, CoinFabrik has been providing Quality Assurance as a service to development teams, accumulating valuable expertise in the field for a considerable period of time. Our clients highly appreciate this service, and as a result, we are eager to expand our capabilities to the ink! ecosystem. + + +### Team Code Repos + +- https://github.com/CoinFabrik +- https://github.com/CoinFabrik/on-ink-integration-tests +- https://github.com/CoinFabrik/scout +- https://github.com/CoinFabrik/web3-grant + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/arielwaissbein/ +- https://www.linkedin.com/in/agustin-aon/ +- https://www.linkedin.com/in/valeriacaracciolo/ + + +## Development Status :open_book: + +We have identified 24 functions exposed for their usage in integration and E2E tests in the file [env_access.rs](https://github.com/paritytech/ink/blob/master/crates/ink/src/env_access.rs) of the ink! repository. Of these 24 functions, we determined that there are 9 functions to work on with explicit plans, and 13 functions for which there might be implementation differences that remain to be analyzed. Two functions were deemed unfeasible for their implementation in the integration testing environment. + + +**Table 1: Status of functions exposed in integration and e2e testing environments.** +| Issue Number | Function | Implemented Integration Tests | Implemented Integration E2E Tests | Status | +|--------------|-----------------------------|-------------------------------|------------------------|------------------------------------------------------------------------------------------------| +| 1 | default_accounts() | Yes | Yes | Implementation Difference. | +| 2 | set_contract_storage() | Yes | Yes | Missing limitation on Integration Testing. | +| 3 | invoke_contract_delegate() | No | Yes | Missing Function Implementation on Integration Testing. | +| 4 | invoke_contract() | No | Yes | Missing Function Implementation on Integration Testing | +| 5 | gas_left() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 6 | set_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 7 | instantiate_contract() | No | Yes | Missing Function Implementation on Integration Testing. | +| 8 | caller_is_origin() | No | Yes | Missing Function Implementation on Integration Testing. | +| 9 | code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 10 | own_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 11 | call_runtime() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 12 | caller() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 13 | transferred_value() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 14 | weight_to_fee() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 15 | block_timestamp() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 16 | account_id() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 17 | balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 18 | block_number() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 19 | minimum_balance() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 20 | terminate_contract() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 21 | transfer() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 22 | hash_bytes() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 23 | hash_encoded() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | +| 24 | ecdsa_recover() | Yes | Yes | Pending Analysis for Corrections in Implementation Differences. | + +For these two sets of functions, with explicit implementation plans and pending analysis, the following work remains to be performed. +- The implementation and correction of implementation differences of the 9 functions with explicit plans. These are the functions with issue numbers 1, 2, 3, 4, 6, 7, 8, 9, 10. +- An analysis of the remaining 13 functions, which are implemented both for integration and E2E tests, in order to first estimate and then correct implementation differences (if any). These correspond to functions issue numbers 12 through 24. +- QA: Adding tests to integrate the functions we add or modify to the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). +- Report Describing our Contribution. + +Considering the dependency of several functions on the implementation of `instantiate_contract()`, we propose to split the work above into two milestones. All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). + +We have also identified a bug in the e2e tests. When contracts are in a workspace with dependencies defined in `Cargo.toml`, and these dependencies are inherited in contracts, the e2e tests fail to compile. However, manually specifying dependencies in each contract resolves the issue. We've logged this bug on GitHub [Issue #1919](https://github.com/paritytech/ink/issues/1919) and will be addressing it as part of our work in Milestone 1. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 weeks +- **Full-Time Equivalent (FTE):** 4 FTE +(0.50 Project Manager, +0.50 Tech Lead, +1 Full time Sr Rust Developer, +1 Full Time SemiSr Rust Developer, +1 Full Time QA Specialist) +- **Total Costs:** 30,000 USD + +### Milestone 1: Execution and Further Analysis +- **Estimated duration:** 4 weeks +- **FTE:** 4 +- **Costs:** 30,000 USD + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the functions to be implemented/corrected in this milestone, corresponding to issues 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract().

Documentation and test cases will be provided for the 13 functions with remaining analysis. If implementation differences are found in these functions, an estimate for their correction and an implementation idea will also be provided in our report.

If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing. +| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/. + **1** | Develop | We will develop the missing functionalities or correct implementation differences for functions 1-default_accounts(), 2-set_contract_storage() and 7-instantiate_contract(). All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).

If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing. + **2** | Review and Estimate | We will review the remaining 13 unanalysed functions, which are implemented both for integration and e2e tests. For these functions we will provide documentation, a test case and an implementation estimation if applicable. These correspond to functions issue numbers 12 through 24. + **3** | Quality Assurance | We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink). + + + +## Future Plans + +After finishing the Milestone 1: Execution and Further Analysis, we will submit a new grant proposal to continue with the implementation of the remaining functions. We will include specific references to developments associated with the estimations resulting from the further analysis of functions issue numbers 12 through 24. + +### Next Milestone: Execution +- **Estimated duration:** 4 weeks +- **FTE:** 4 +- **Costs:** 30,000 USD + + + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().

Our report will also document the implementation of any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work that was required in order to ensure consistency between integration and e2e tests.

If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the env_access.rs file, but that could be related to integration or e2e testing. +| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/. + **1** | Development | We will implement the missing functionalities or resolve implementation differences for function issues 3-invoke_contract_delegate(), 4-invoke_contract(), 6-set_code_hash(), 8-caller_is_origin(), 9-code_hash(), 10-own_code_hash().

We will implement any missing functionalities, or correct implementation differences, for the 13 functions with issues 12 through 24. For this group, we will document any additional work required in order to ensure consistency between integration and e2e tests.

All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).

If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the env_access.rs file that might be related to integration or end-to-end testing. +**2** | Quality Assurance| We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink). + + +Moving forward, we have two projects in mind: + +- Research and develop an advanced testing automation solution for ink! smart contracts. +- Improve our open source bug-detection tool [Scout](https://coinfabrik.github.io/scout/ ). + + + +## Referral Program (optional) :moneybag: + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result. + +During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation. + diff --git a/applications/CoinFabrik_On_Ink_Integration_Tests_3.md b/applications/CoinFabrik_On_Ink_Integration_Tests_3.md new file mode 100644 index 00000000000..f2c23693b53 --- /dev/null +++ b/applications/CoinFabrik_On_Ink_Integration_Tests_3.md @@ -0,0 +1,159 @@ +# CoinFabrik On Ink Integration Tests 3 +- **Team Name:** CoinFabrik (Nektra S.A) +- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +We have discovered that integration tests for ink! contracts lack some of the functionalities, or present implementation differences, when compared to E2E testing. + +Integration tests run significantly faster than E2E (end-to-end) tests. If a full range of functionalities were provided, it could reduce testing and QA times. + +Our intention is to `flatten the anvil` of ink! integration testing. With a properly flattened anvil, quality tools can be built. + + +### Project Details + +We have conducted a comprehensive analysis to identify any missing functionalities in integration tests and implementation differences with E2E tests, and to propose and develop new testing features based on our findings. This analysis was carried as part of two previous grants ([link1](https://github.com/w3f/Grant-Milestone-Delivery/pull/998), [link2](https://github.com/w3f/Grant-Milestone-Delivery/pull/1043)). As part of the latter grant, we have developed and resolved the issues with some of the functions with implementation differences or missing implementations: `default_accounts()`, `set_contract_storage()` and `instantiate_contract()`. + +With this new grant, our objective is to implement our findings. Specifically, we aim to address functions in integration testing that have missing implementations or show differences when compared to e2e tests. We will add our contributions into the [ink! project repository](https://github.com/paritytech/ink ) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). + + +### Ecosystem Fit + +Having a comprehensive set of functionalities available for integration tests would bring numerous benefits to the entire community, including improved reliability, code quality and maturity, and faster feedback loops. + +Integration tests are useful during their development and they are quicker than E2E tests. We learned this while working on fuzzing detection techniques during the [Proof of Concept of Scout](https://github.com/CoinFabrik/web3-grant), which we performed in collaboration with [researchers from the University of Buenos Aires](https://lafhis.dc.uba.ar/home). We believe that having a complete set of functionalities for integration tests would be useful for other teams working in the development of ink! smart contracts. + +## Team :busts_in_silhouette: + +### Team members + +- Ariel Wassbein, Head of Research. +- Valeria Caracciolo, Business Development. +- CoinFabrik's development and QA teams. + + +### Contact + +- **Contact Name:** Valeria Caracciolo +- **Contact Email:** valeria.caracciolo@coinfabrik.com +- **Website:** https://www.coinfabrik.com/ + + +### Legal Structure + +- **Registered Address:** Dr. Emilio Ravignani 2394, C1425 CABA, Argentina +- **Registered Legal Entity:** Nektra S.A + + +### Team's experience + +We are a research and development company specialized in Web3, with a strong background in cybersecurity. Founded in 2014, we have worked on over 200 blockchain-related projects, EVM based and also for Solana, Algorand, and Polkadot. Beyond development, we offer security audits through a dedicated in-house team of senior cybersecurity professionals, currently working on code in Substrate, Solidity, Clarity, Rust, and TEAL. + +Our team has an academic background in computer science and mathematics, with work experience focused on cybersecurity and software development, including academic publications, patents turned into products, and conference presentations. Furthermore, we have an ongoing collaboration on knowledge transfer and open-source projects with the University of Buenos Aires. + +As well, CoinFabrik has been providing Quality Assurance as a service to development teams, accumulating valuable expertise in the field for a considerable period of time. Our clients highly appreciate this service, and as a result, we are eager to expand our capabilities to the ink! ecosystem. + + +### Team Code Repos + +- https://github.com/CoinFabrik +- https://github.com/CoinFabrik/on-ink_implementations +- https://github.com/CoinFabrik/on-ink-integration-tests +- https://github.com/CoinFabrik/scout +- https://github.com/CoinFabrik/web3-grant + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/arielwaissbein/ +- https://www.linkedin.com/in/valeriacaracciolo/ + + +## Development Status :open_book: + +We have identified and analyzed 24 functions exposed for their usage in integration and E2E tests in the file [env_access.rs](https://github.com/paritytech/ink/blob/master/crates/ink/src/env_access.rs) of the ink! repository. We documented these functions and provided test cases comparing their behaviour in integration and end-to-end tests. This analysis can be found in our [analysis repository](https://github.com/CoinFabrik/on-ink-integration-tests). + +Of these 24 functions, 4 functions showed behaviour differences when comparing their implementations for integration and e2e tests, 9 showed missing implementations for integration tests and the remaining 11 functions showed a consistent implementation across both environments. + +In the table below, we provide the status of each function after the developments and analysis made in our previous milestones. + +**Table 1: Status of functions exposed in integration and e2e testing environments.** +| Issue Number | Function | Implemented Integration Tests | Implemented E2E Tests | Status | +|--------------|-------------------------------|-------------------------------|----------------------------------|--------------------------------------------------------------------------| +| 1 | default_accounts() | Yes | Yes | Implementation Difference Corrected. [Pull request performed](https://github.com/paritytech/ink/pull/1955). | +| 2 | set_contract_storage() | Yes | Yes | Missing limitation on Integration Testing Implemented. [Pull request performed](https://github.com/paritytech/ink/pull/1961). | +| 3 | invoke_contract_delegate() | No | Yes | Missing Function Implementation on Integration Testing. | +| 4 | invoke_contract() | No | Yes | Missing Function Implementation on Integration Testing | +| 5 | gas_left() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 6 | set_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 7 | instantiate_contract() | No. [Pull request performed](https://github.com/paritytech/ink/pull/1963). | Yes | Missing Function Implementation on Integration Testing Performed. [Pull request performed](https://github.com/paritytech/ink/pull/1963). | +| 8 | caller_is_origin() | No | Yes | Missing Function Implementation on Integration Testing. | +| 9 | code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 10 | own_code_hash() | No | Yes | Missing Function Implementation on Integration Testing. | +| 11 | call_runtime() | No | Yes | Missing Function Implementation on Integration Testing. Unfeasible Implementation. | +| 12 | caller() | Yes | Yes | Ok. No difference observed in testing. | +| 13 | transferred_value() | Yes | Yes | Ok. No difference observed in testing. | +| 14 | weight_to_fee() | Yes | Yes | Implementation Difference. | +| 15 | block_timestamp() | Yes | Yes | Ok. No difference observed in testing. | +| 16 | account_id() | Yes | Yes | Ok. No difference observed in testing. | +| 17 | balance() | Yes | Yes | Implementation Difference. | +| 18 | block_number() | Yes | Yes | Ok. No difference observed in testing. | +| 19 | minimum_balance() | Yes | Yes | Ok. No difference observed in testing. | +| 20 | terminate_contract() | Yes | Yes | Ok. No difference observed in testing. | +| 21 | transfer() | Yes | Yes | Ok. No difference observed in testing. | +| 22 | hash_bytes() | Yes | Yes | Ok. No difference observed in testing. | +| 23 | hash_encoded() | Yes | Yes | Ok. No difference observed in testing. | +| 24 | ecdsa_recover() | Yes | Yes | Ok. No difference observed in testing. | + +In this milestone, we will develop the remaining functions that either lack implementations in integration tests or exhibit differences in implementation when compared to E2E tests. However, we will make exceptions for `gas_left()` and `call_runtime()`, as our analysis has deemed implementing these functions in integration tests unfeasible. + +**Observations for function `weight_to_fee()`:** + +For the function `weight_to_fee()`, we have observed in the [milestone report of our previous grant delivery](https://github.com/CoinFabrik/on-ink-integration-tests/blob/milestone-on-ink-integration-tests-2/assets/On-Ink-Integration-Tests-2-Milestone-Report.pdf) and in the provided [test case](https://github.com/CoinFabrik/on-ink-integration-tests/tree/main/test-cases/weight-to-fee) that the value obtained in e2e tests is fixed at 0 and cannot be modified. This incorrect behaviour of `weight_to_fee()` in E2E tests is also observed in paritytech/substrate-contracts-node. + +We have reviewed the function `weight_to_fee()` and found that it has multiple implementations. This complexity makes it challenging to identify which implementation is responsible for the E2E tests, especially given that the large size of the runtime significantly slows down debugging. + +To address this issue, we will submit an initial report to the ink! development team in the first week of this milestone and collaborate to devise an implementation plan. If we deem a resolution feasible, we will include it as part of this milestone. + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 weeks +- **Full-Time Equivalent (FTE):** 4 FTE (0.50 Project Manager, 0.50 Tech Lead, 1 Full time Sr Rust Developer, 1 Full Time SemiSr Rust Developer, 1 Full Time QA Specialist) +- **Total Costs:** 30,000 USD + +### Milestone 1: Execution +- **Estimated duration:** 4 weeks +- **FTE:** 4 +- **Costs:** 30,000 USD + +| Number | Deliverable | Specification | +| ----- | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will write a comprehensive report that compares the functionalities of integration tests and E2E (End-to-End) tests. This report will focus on the the functions to be implemented in this milestone, corresponding to issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`, `9-code_hash()`, `10-own_code_hash()`, and `17-balance()`.

In the first week of this milestone, we will contact the ink! development team to provide an initial report on `14-weight_to_fee()`, documenting our efforts to identify the source of its implementation issues and seeking collaboration to assess the feasibility of resolving them. We will document any progress and implementations related to `14-weight_to_fee()` in our final milestone report.

We will document any additional work that was required in order to ensure consistency between integration and e2e tests.

If applicable, we will suggest additional tests outside of the scope of this milestone. Particularly, for functions declared outside of the `env_access.rs` file, but that could be related to integration or e2e testing. +| 0c. | Testing and Testing Guide | The newly developed functionalities will be documented and tested following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md). A testing guide will be included. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will publish an updated report summary in our blog at https://blog.coinfabrik.com/. + **1** | Development | We will implement the missing functionalities or resolve implementation differences for function issues `3-invoke_contract_delegate()`, `4-invoke_contract()`, `6-set_code_hash()`, `8-caller_is_origin()`, `9-code_hash()`, `10-own_code_hash()` and `17-balance()`.
We will also make the necessary changes to address the issues highlighted in our initial report on `14-weight_to_fee()`, provided that these changes are deemed feasible during our discussions with the ink! development team.

All these implementations or modifications will be pushed into the [ink! project repository](https://github.com/paritytech/ink) following existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md).

If applicable, we will develop additional tests or make ad hoc improvements to the ink codebase necessary for the completion of this milestone. Particularly for functions declared outside the `env_access.rs` file that might be related to integration or end-to-end testing. +**2** | Quality Assurance| We will adhere to existing [contribution guidelines](https://github.com/paritytech/ink/blob/master/CONTRIBUTING.md) and add necessary tests to integrate the new implemented or corrected functions to the [ink! project repository](https://github.com/paritytech/ink). + + +## Future Plans + +Moving forward, we have two projects in mind: +- Research and develop an advanced testing automation solution for ink! smart contracts. +- Improve our open source bug-detection tool [Scout](https://coinfabrik.github.io/scout/ ). + +## Referral Program (optional) :moneybag: + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Richard Casey from Parity brought this program to our attention, and we have already successfully delivered two applications as a result. + +During our inquiries for this application, we briefly consulted Sam Ruberti from the ink! Team and David Hawig from the Web3 Foundation. Their encouragement motivated us to proceed with this presentation. + diff --git a/applications/Coinversation.md b/applications/Coinversation.md index 12aa0aa3495..bbefc75bf23 100644 --- a/applications/Coinversation.md +++ b/applications/Coinversation.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Coinversation Protocol -* **Project:** Coinversation Protocol * **Proposer:** [coin-pro](https://github.com/coin-pro) * **Payment Address:** 3FX6TD7Qm255foMg7xZStZNAfpLvDai5P8 * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/233#issuecomment-886535171) diff --git a/applications/Contract_wizard.md b/applications/Contract_wizard.md new file mode 100644 index 00000000000..488cc29d249 --- /dev/null +++ b/applications/Contract_wizard.md @@ -0,0 +1,174 @@ +# Polkadot Contract Wizard +​ +- **Team Name:** Protofire +- **Payment Address:** 0xD662E05ce522B3861b70FC376F60bF50E200abfA (USDC - Ethereum network) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 +​ +## Project Overview :page_facing_up: +​ +The Polkadot Contract Wizard has successfully completed its initial phase, making it easier for users to create and deploy standard smart contracts on the Polkadot ecosystem. In the next phase, we aim to expand the scope of the project by implementing additional features and supporting multiple chains. Our goal is to continue enhancing the user experience and versatility of the Polkadot Contract Wizard, making it a powerful tool for both developers and non-developers. +​ +### Overview +​ +In the next phase, we plan to implement the following features: +​ +1. Interaction with deployed contracts through the wizard's UI. +​ +2. Interaction with smart contracts deployed by the user. +​ +3. Shareable Contract Interaction Links +​ +4. Support for multiple chains +​ +These enhancements will allow users to create, modify, deploy and interact with smart contracts on different parachains, making the Contract Wizard an indispensable tool for the community within the Polkadot and Kusama ecosystem. +​ +### Project Details +​ +#### 1. Interact with deployed contracts +We will create a functionality that enables users to directly interact with their deployed contracts via the user interface of the wizard. This functionality will be generated dynamically according to the metadata of the contracts. With this, users will be able to conveniently and effectively manage their contracts and carry out interactions using the same tool. +​ +#### 2. Interaction with custom smart contracts +Our platform will offer the capability to interact with any contract of their choice. To utilize this feature, they simply need to provide the metadata, network, and address associated with the contract. Once this information is ready, the user interface will automatically generate a customized user-friendly layout for allowing people to easily interact with their custom contracts. +​ +#### 3. Shareable Contract Interaction Links +To enhance the user experience and encourage collaboration, we plan to implement a feature for shareable contract interaction links. +Once a developer deploys a contract or uploads the metadata for interacting with it on our platform, they can generate a unique, shareable link. This link will contain all necessary information for interacting with the contract, essentially encapsulating the contract's ABI (Application Binary Interface) and its address on the blockchain. +Users receiving this link can interact with the contract directly, without needing to reupload the metadata or know the contract's specifics. This feature not only simplifies the process of contract interaction but also fosters collaboration and sharing within the developer community. +​ +#### 4. Support for multiple chains +This tool will offer a feature that enables users to connect to parachains implementing the contracts pallet. We will provide a list of some of these parachains in Polkadot, Kusama, and Rococo networks. Additionally, users will have the option to connect to a network that is not listed by specifying the web socket. +​ +### Tentative Mockups + +![](https://github.com/protofire/assets/blob/c18c2adb8f40c692134bffbb4e92e0a78872744e/add_contract_1_720.png?raw=true) + +![](https://github.com/protofire/assets/blob/c18c2adb8f40c692134bffbb4e92e0a78872744e/add%20contract%202.png?raw=true) + +![](https://github.com/protofire/assets/blob/c18c2adb8f40c692134bffbb4e92e0a78872744e/add%20contract%203.png?raw=true) + +![](https://github.com/protofire/assets/blob/c18c2adb8f40c692134bffbb4e92e0a78872744e/networks%201.png?raw=true) + +![](https://github.com/protofire/assets/blob/c18c2adb8f40c692134bffbb4e92e0a78872744e/networks%202.png?raw=true) + +### Ecosystem Fit +​ +The Polkadot Contract Wizard aims to streamline the onboarding process and enhance usability within the Polkadot and Kusama ecosystem. +​ +This project will contribute to the ecosystem in the following ways: +​ +1. **Simplifying smart contract creation**: The Polkadot Contract Wizard will offer a user-friendly interface that allows individuals with varying levels of technical expertise to create smart contracts without the need for extensive programming knowledge. This will empower more people to participate in the ecosystem and explore the possibilities offered by smart contracts. +​ +2. **Enhancing user experience**: By providing video tutorials, detailed documentation, and an intuitive interface, we will create a welcoming environment for new users, making it easier for them to get started with smart contracts on Polkadot and Kusama. +​ +3. **Expanding the ecosystem's reach**: With the inclusion of multiple chains and custom contract creation, the Polkadot Contract Wizard will cater to a broader audience, encouraging more projects and developers to join the Polkadot and Kusama ecosystem. +​ +4. **Encouraging community growth and collaboration**: By offering comprehensive support and resources, we aim to foster a strong, collaborative community around the Polkadot Contract Wizard, encouraging users to share their experiences, contribute to the project, and help one another succeed. +​ +5. **Driving innovation and adoption**: By simplifying the process of working with smart contracts, we hope to inspire more users to experiment with new ideas and solutions, driving innovation and adoption within the Polkadot and Kusama ecosystem. +​ +## Team :busts_in_silhouette: +​ +### Team members +​ +- Diego Torres (Team leader / Product Owner) +- Gabriel Gonzalez (Rust Engineer) +- Luca Auet (Rust Engineer) +- Agustin Longoni (UI/UX Designer) +- Henry Palacios (Front-end engineer) +​ +### Contact +​ +- **Contact Name:** Diego Torres Borda +- **Contact Email:** diego@protofire.io +- **Website:** [protofire.io](https://protofire.io/) +​ +### Legal Structure +​ +- **Registered Address:** 1607 Ponce de Leon Avenue, GM-06, San Juan, PR, 00909 +- **Registered Legal Entity:** Altoros LLC (DBA Protofire) +​ +### Team's experience +​ +Protofire has proven expertise in building decentralized infrastructure, protocols, applications, and developer platforms to accelerate growth of network’s ecosystems. By delivering hands-on coding and contributions, Protofire specializes in supercharging developer adoption, bootstrapping, and network usage +We are not only a dev shop company, but we create long term partnerships with the projects we are part of, building and working as ambassadors for the community. We believe in the projects and also participate by running nodes and taking the validator or staker roles. +​ +### Team Code Repos +​ +- https://github.com/protofire/polkadot-contract-wizard/ +- https://github.com/protofire/ink-compiler-be +- https://github.com/protofire/moonbeam-web-core +- https://github.com/protofire/blockchain-learning-path +- https://github.com/protofire/omen-exchange +- https://github.com/protofire/kyber-pool-master-proxy-contract + +GitHub accounts of team members. +- https://github.com/alongoni Agustin Langoni +- https://github.com/henrypalacios Henry Palacios +- https://github.com/0xLucca Luca Auet +- https://github.com/GabrielCamba Gabriel Gonzalez +​ +### Team LinkedIn Profiles +​ +- https://www.linkedin.com/in/diego-torres-borda-94b70912/ +- https://www.linkedin.com/in/agustinlongoni/ +- https://www.linkedin.com/in/henrydpalacios/ +- https://www.linkedin.com/in/lucaauet/ +- https://www.linkedin.com/in/gabriel-nicolas-gonzalez/ +​ +## Development Status :open_book: +​ +We have successfully completed the previous grant, and we can confidently affirm that our platform, [contractwizard.xyz](https://www.contractwizard.xyz/), is now a user-friendly and highly useful tool. One of the key features of our platform is that it simplifies the deployment of standard smart contracts within the Dotsama ecosystem. With our platform, users no longer have to navigate through complex processes to deploy their contracts. Our streamlined approach means that anyone can deploy a smart contract without requiring advanced technical knowledge, saving time and resources. We are incredibly grateful for the support we have received so far, and we are committed to ensuring that our platform remains a top choice for deploying smart contracts within the Dotsama ecosystem. +​ +## Development Roadmap :nut_and_bolt: +​ +Described in project details. +​ +### Overview +​ +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2.5 +- **Total Costs:** 52500 U$D +​ +## Milestones +​ +### Milestone 1 — Functionality Implementation and Educational Content +​ +- **Estimated duration:** 3 months +- **FTE:** 2.5 +- **Costs:** 52500 + + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can use the new features. | +| **0c.** | Testing and Testing Guide | The code will have unit-test coverage to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile that allows users to easily run the application. | +| 1. | Interaction with deployed contracts | The functionallity based on [step 1](#step1) of the Project Details section. | +| 2. | Interaction with custom smart contracts | The functionality based on [step 2](#step2) of the Project Details section. | +| 3. | Shareable Contract Interaction Links | The functionality corresponds to what's described on [step 3](#step3) of the Project Details section. | +| 4. | Support for multiple chains | The functionality to be implemented corresponds to [step 4](#step4) of the Project Details section. | + +​ +## Future Plans +​ +At contractwizard.xyz team in protofire, our mission is to continue innovating and developing our platform to cater to the ever-changing needs of the smart contract community. We recognize the importance of providing our users with a comprehensive tool that enables them to manage all ink! smart contracts, including those they have created custom. +​ +As we continue to develop our platform, we understand the importance of building a community around it. We believe that by creating a community of users, we can facilitate the sharing of knowledge, contracts, and different approaches to problem-solving. Through our platform, users will have the ability to share their experiences, ask questions, and engage with others within the community. This will create an environment that fosters innovation and encourages collaboration, leading to the development of new and exciting ideas. Our hope is that our platform will serve as a hub for all things smart contract-related, where users can come together to learn, grow, and innovate. + +**Custom contracts** +- Add the possibility of creating custom contracts, not only with the modifiers but adding the ability to write code using the interface. +- Compile the generated code and deploy it to different parachains. +- Following the comments made on the [pull request](https://github.com/w3f/Grants-Program/pull/1413#pullrequestreview-1234970716), our approach will be based on the [ink-playground](https://github.com/paritytech/ink-playground) in order to integrate writing custom code and compiling it. + +**Social Interaction** +- Create an account to store information. +- Save your created smart contracts. +- Be able to share them with the community and ask for help. +- Provide assistance to other community members. +​ +## Additional Information :heavy_plus_sign: +​ +**How did you hear about the Grants Program?** + +Web3 Foundation Website diff --git a/applications/CosmWasmVM-CoreProduct.md b/applications/CosmWasmVM-CoreProduct.md new file mode 100644 index 00000000000..7cc754b3fba --- /dev/null +++ b/applications/CosmWasmVM-CoreProduct.md @@ -0,0 +1,179 @@ +# CosmWasm VM - Core product + +- **Team Name:** Composable Finance LTD +- **Payment Address:** (USDC) 0x7C0776FBfadcB5EeEA5eF1DC5b50d603c9a40621 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +Composable Finance focuses on trustless, cross-chain communications between Polkadot and other ecosystems. +In this case, a CosmWasm VM is a supplementary component to onboarding a new developer community and a widely adopted smart contract framework. + +### Overview + +The first CosmWasm VM implementation in Substrate for the Polkadot and Kusama ecosystems. + +CosmWasm, short for Cosmos Webassembly, is a smart contract framework designed for use in the Cosmos ecosystem. +Originally, the CosmWasm specification was built as a Cosmos SDK module and currently provides a plug-and-play functionality for Cosmos chains. +CosmWasm was written in half Rust and half Golang (Go), with low-level calls in Rust and high-level dispatching logic, handled in Go. +The actor model is implemented in Go which then calls the low-level Rust library to execute contracts effectively. + +CosmWasm offers a high degree of customization as part of its design philosophy. +A key feature of CosmWasm is that it allows for multi-chain contracts; one dApp, one contract, but multiple chains. +As a result, CosmWasm allows users to benefit from the utility across chains instead of being forced to choose between them. +Implementing the CosmWasm framework in Substrate will allow developers and parachains in the Polkadot and Kusama ecosystems +to seamlessly interact with a well-tested and heavily adopted smart contract framework. + +In terms of security, CosmWasm is designed to avoid the attack vectors found in Ethereum and Solidity, such as Reentrancy, and Default Visibilities. +Its security is further reinforced by its well-developed tooling and testing mechanisms prioritized early in its conception. +Due to these benefits, many projects have adopted CosmWasm as their smart contract framework, +including notable examples like Juno, OKX, and Osmosis. + +Overall, the CosmWasm VM proved to be the best VM for our needs as we found it to be the most portable and robust solution. +CosmWasm was built with interoperability in mind from the very beginning, +the goal being to build a smart contracting framework capable of operating across multiple blockchains. +By utilizing the XCMP as a transport layer, +CosmWasm contracts would be able to communicate with each other on different parachains without the need for any trusted parties. +The entire Dotsama ecosystem has the potential to benefit from CosmWasm. +This means that any team building on Dotsama will have unparalleled reach, +and the potential to create applications that have never been seen before. + + +### Project Details + +In its current state, Confio’s implementation of the CosmWasm VM excludes library components and consists of a single implementation targeting the Cosmos SDK. +Our team is building a library implementation of CosmWasm that can be utilized by different host implementations to minimize the work to port Cosmwasm to different ecosystems. +Currently, the only implementation of CosmWasm consists of half of it written in Rust and half Golang. +Therefore, the current version was not compatible with Substrate and has never been leveraged outside of Cosmos. +This meant we had to build a VM from scratch. + +Furthermore, we have two host implementations which allows developers to integrate CosmWasm in their ecosystems in a straightforward manner. +This ensures that our CosmWasm VM is highly portable with consistent execution semantics regardless of its host. +As a result, this would enable developers to integrate our CosmWasm VM as a pallet, within a frontend app, or inside a CLI tool. + +The official CosmWasm VM uses Wasmd for the runtime. +It ensures that developers follow the same execution semantics, +thus, all CosmWasm contracts will function the same irrespective of the Cosmos blockchain they are executed on. +We utilized the Wasmd reference material to rewrite the Go portions of CosmWasm in Rust for implementation on our parachains. + +![high_level_overview](https://drive.google.com/uc?id=1zcIT6UHveRrUfZunNx6otKuMCerEdX2J) + +- Documentation of core components, protocols, architecture, etc. to be deployed +- https://book.cosmwasm.com/ +- https://docs.cosmwasm.com/docs/1.0/ +- https://cosmwasm.com/resources + + +- PoC/MVP or other relevant prior work or research on the topic: +- https://medium.com/cosmwasm/cosmwasm-for-ctos-f1ffa19cccb8 +- https://medium.com/cosmwasm/cosmwasm-for-ctos-i-the-architecture-59a3e52d9b9c +- https://medium.com/cosmwasm + +### Ecosystem Fit + +CosmWasm would be able to facilitate the orchestration of cross-chain smart contracts between different parachains. + +Our target audience consists of parachain builders, +and dApps in the Dotsama ecosystem that want to leverage a WASM based smart contracting framework. +We hope this VM enables and incentivizes developers to build in the Polkadot ecosystem as CosmWasm has been adopted by a large developer community. + +We are the only team in the Substrate/Polkadot/Kusama ecosystem implementing CosmWasm for Substrate. + +## Team :busts_in_silhouette: + +### Team members + +- Name of team leader: Blas Rodriguez +- Names of team members: Dzmitry Lahoda, Kostya Kastsevich + +### Contact + +- **Contact Name:** Ahmad Wehbi +- **Contact Email:** ahmad@composable.finance +- **Website:** https://www.composable.finance/ + +### Legal Structure + +- **Registered Address:** + + FortGate Offshore Investment and Legal Services LTD, + + 1st Floor, The Sotheby Building, Rodney Bay, Gros-Islet, + + P.O. Box 838, Castries, Saint Lucia +- **Registered Legal Entity:** Composable Finance LTD + +### Team's experience + +- Blas Rodriguez: CTO at Composable Finance +- Dzmitry Lahoda: Senior staff engineer at Composable Finance +- Kostya Kastsevich: Parachain Lead at Composable Finance + +### Team Code Repos + +- https://github.com/ComposableFi/cosmwasm-vm + +GitHub accounts of all team members: + +- https://github.com/blasrodri +- https://github.com/dzmitry-lahoda +- https://github.com/kkast + +### Team LinkedIn Profiles (if available) + +- https://ar.linkedin.com/in/blas-rodriguez-irizar + +## Development Status :open_book: +https://medium.com/supercolony/a-look-into-virtual-machines-and-smart-contract-runtimes-313cd7d494e3 + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** February 2023 - September 2023 +- **Full-Time Equivalent (FTE):** 1,5 FTE +- **Total Costs:** 29,700 USD + +### Milestone 1 — Pallet CosmWasm VM + +- **Estimated duration:** 8 weeks +- **FTE:** 1,5 +- **Costs:** $21,600 + +| Number | Deliverable | Specification | +|--------:|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **0a.** | License | GPLv3 / MIT / | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can test and execute transactions using cosmwasm vm pallet. | +| **0c.** | Testing Guide | Core functions will be fully covered by integration tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile that can be used to test the pallet functionality. | +| **1a.** | Development | We will deliver the core pallet for the CosmWasm VM | +| **1b.** | Development | This milestone includes the pallet supporting the following features: XCM integration, native asset support, allow calling extrinsics, verification through Fuzzing & Kani and Benchmarking. | | +| **1c.** | Testing | A local network setup running a substrate chain with the pallet and a contract showing the functionality described in the milestones, so that it can be inspected and called through Polkadotjs.org. | + +### Milestone 2 — PolkadotJS Integration + +- **Estimated duration:** 3 weeks +- **FTE: 1.5** +- **$8,100** + + +| Number | Deliverable | Specification | +|--------:|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **0a.** | License | GPLv3 / MIT | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how contracts interact with PolkadotJS. | +| **0c.** | Testing Guide | Core functions will be fully covered by integration tests to ensure functionality and robustness. | +| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone | +| **0e.** | Article | We intend to publish an article which outlines what was achieved as part of the grant, how it benefits the Substrate ecosystem and how other parachains can utilize the pallet. | +| **1.** | Development | This milestone would include PolkadotJS support querying contracts’ state and interacting with CosmWam contracts | + + +## Future Plans + +Composable is continuing to contribute upstream, further pushing the boundaries of cryptographic research and opening up endless possibilities for the Dotama ecosystem as we work in line with our cross-chain/cross-layer interoperability goals. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Web3 Foundation Medium and Twitter + diff --git a/applications/Crowdloans-FET.md b/applications/Crowdloans-FET.md new file mode 100644 index 00000000000..7a8eeb59320 --- /dev/null +++ b/applications/Crowdloans-FET.md @@ -0,0 +1,169 @@ +# The CrowdloanFET Project + +- **Team Name:** Mutai Solutions +- **Payment Address:** 0xE27F2E8321Fb4c32525a4ED86d2902dbA63491E4 Ethereum (USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1280#issuecomment-1583327825) + +## Project Overview :page_facing_up: + + **This application is response to the [Crowdloan Front End Template RFP](https://github.com/w3f/Grants-Program/blob/master/rfps/open/crowdloan_front_end_template.md)** + +The CrowdloanFET project is a free and opensource white-label solution for Polkadot projects to showcase the Crowdloan to prospective and current project supporters and community members. + +Built using Nextjs, Tailwind and Polkadotjs, projects can easily configure/modify and deploy a frontend for their crowdloan campaign, either on their own infrastructure that supports node or on affordable/free platforms like Vercel. + +The template will come with an unopinionated style and will provide the appropriate information architecture for different projects to add on top of and apply their own brand assets. + + +## Project Details + +### Technology stack overview: + + - Framework: **Next.js**, built using Typescript + - Styling and branding config: **Tailwind** + - Wallet/on-chain data & network interactions: **Polkadotjs** + +### Configuration: + +To make the template generic & simple to configure, we shall use 3 main points of modifation: + +- **Markdown Files** - To populate the project copy thorough various sections of the template +- **.ENV configuration file** - To configure various settings that may be required for querying data on-chain and various other uses around the template. A few config variables to include would be: `PARA_ID`, `HOMEPAGE_LINK`, `DISCORD_INVITE_LINK`, `TWITTER_ACCOUNT_USERNAME`, `BLOG_LINK`, etc +- **Tailwind.config.js** - To configure key branding aspects. e.g Colours, Font, etc + +These as well as further configuration steps shall be outlined the accompanying documentation and tutorial article. + + +### Mockups: + +### Project Overview/Description Section + +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202225912-19b5906d-e532-40ce-bfb4-376d44bf381c.png) + + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202226004-2c7ac951-db82-4704-8c58-e744d9aa28e1.png) + + +### Crowdloan details & timeline Section +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202226870-2e319a79-5d36-441b-90df-6c670f4fc995.png) + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202226931-d3da8dfc-b45e-42fe-ad80-99c21e460a67.png) + +### Crowdloan Rewards Section: + +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202229039-c810bde8-8860-43da-a165-02c89d5e6e6c.png) + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202229444-51223716-aa35-440d-9db2-8a177f927eb1.png) + + +### Crowdloan Contributions Section: + +**Wireframe** + +![image.png](https://user-images.githubusercontent.com/14836056/202388654-9b8bb827-a74d-4885-b767-d282f8f4e575.png) + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202388697-b7971a33-1adb-4d42-9115-f81802c251ec.png) + +### Competing crowdloans Section: + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202399108-f1c388fd-06df-4c46-9e1d-030c7719f4b2.png) + + +### FAQ Section: + +**Example Mockup** + +![image.png](https://user-images.githubusercontent.com/14836056/202399482-2cf6ba84-bff1-4845-bbfd-7aaca1919203.png) + + +### Ecosystem Fit + +As outlined above in the Project Overview, this project is targeted toward project maintainers and their respective communities/contributors that are undertaking a crowdloan campaign. This ideally would help with eliviating some of the workload on the project maintainers while also providing conclusive visibility of a crowdloan to the wider Polkadot ecosystem at large and an easy approach to contributing to it. + +Similar implementations/projects: + + - https://acala.network/acala/join-acala + - https://mantanetwork.medium.com/the-calamari-crowdloan-on-kusama-74a3cb2a2a4b + +## Team :busts_in_silhouette: + +### Team members + +- **Bryan Mutai** : Full-Stack developer and web designer + +### Contact + +- **Contact Name:** Bryan Mutai +- **Contact Email:** work@bryanmutai.co + +### Legal Structure + +- **Registered Address:** 90 JGO, James Gichuru Road, Lavington, Nairobi, Kenya - P.O.Box 1669-00100 Nairobi GPO +- **Registered Legal Entity:** Mutai Solutions + +### Team's experience + +I studied software engineering at the University of Glasgow, I currently have 5 years experience in web design & development and have been working as a freelance web developer, working in various programming languages (Typescript/Python) and in various frameworks and libraries (React/Angularjs/Django). Over the past 2 years I have also been contributing towards various blockchain related opensource projects. Recently in particular: + +- Designed & built a Voting Delegation Dashboard for the APWine DAO using React/Typescript/Tailwind - https://vote-delegation-dashboard.vercel.app/ +- Contributions to the Shapeshift Web App & related KeepKey hardware wallet features. - https://github.com/shapeshift/web/commits?author=brymut +- Integrating price data for Superfluid tokens into the Gnosis Safe web app backend - https://github.com/safe-global/safe-eth-py/pull/381 +- Added support for Zora NFTs viewing & the Celo blockchain onto the Mask.io browser plugin - https://github.com/DimensionDev/Maskbook/commit/810999f38a09df8d5cefb490b4ca475b837458bc & https://github.com/DimensionDev/Maskbook/commit/c5cfdf393baf6cf7997f66cbabc5e5952dc8cb4d +- Github Page: [https://github.com/team_member_1](https://github.com/brymut/) + +### Team LinkedIn Profiles + +- [https://www.linkedin.com/in/bryanmutai/](https://www.linkedin.com/in/bryanmutai/) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration**: 1 Month +- **Full-Time Equivalent (FTE)**: 1 +- **Total Costs**: 5,600 USD + +### Milestone 1 + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 5,600 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can deploy an instance of the template for their project| +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.| +| 0e. | Article | We will publish an article that explains the core functionality of the template and intended use as well as a step by step tutorial targeted towards developers on how to configure, modify & deploy the template on a popular hosting platform like Vercel | +| 1. | Template User interface implementation | I will design and implement the template UI using Tailwind in the Nextjs framework. The user interface will include: Project information, rewards schema, current contributions, time left in the crowdloan and information on the contribtions made after the crowdloan ends as shown simulated in the mockups above | +| 2. | Contribution form & interaction | A simple interface for users to contribute directly through the deployed template through the entire cycle contribution, handling both a finalised contribution as well as any encountered errors | +| 3. | Example User interface | Using the output from 1 & 2 I will create a sample crowdloan deployment that would be the result of implementing the Front End template following the steps outlined in the output from 0d. | + + +## Future Plans + +- Core maintainance of project, such as critical bugs and security updates +- Implementing/merging community suggestions/Pull Requests on features that could help improve the experience of both deploying and using the template. +- Collecting feedback from projects that consider/use this template. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/Cyborg.md b/applications/Cyborg.md new file mode 100644 index 00000000000..d8aa2a85d7c --- /dev/null +++ b/applications/Cyborg.md @@ -0,0 +1,188 @@ +# Cyborg Network - Empowering Decentralized Edge Networks + +- **Team Name:** Cyborg Network +- **Payment Address:** 12Enn321pZSZkNtBwsTRxxZTKS9DsGpk8PTkZsnsMjTzrtFa (AssetHub USDT) +- **DOT Vesting Address:** 15p7mTm9uKt1w7GF3AU1TNPWm4eAHgieTjtfsVVEtqHazpaY +- **Level:** 1 + +## Project Overview :page_facing_up: + +![Untitled design (1)](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/a33de305-fba2-4a43-ac73-fe3736c03b56) + +### Overview + +This application is a follow up from our previous [grant application](https://github.com/w3f/Grants-Program/pull/1933) + +Cyborg Network is developing a DePIN based marketplace for edge computing servers to help AI and IoT companies boost their performance while curbing the cloud operations cost, all without necessitating a shift from their current cloud setups. Our vision is to act as a crucial middleware on the network's edge, managing specific low-latency tasks and reduce the costs associated with cloud operations, all the while complementing existing cloud services. As a premier venture of this nature in the Polkadot landscape, our network effortlessly allows providers to integrate their machines, rewarding them for their invaluable contribution. + +We establish connections with small to medium-sized data centers to address the demands of enterprise-level clients, ensuring that their requirements are fully met. Our primary emphasis lies in delivering tailored service packages, meticulously designed for diverse deployment scenarios. Our overarching goal is to provide users with a service experience reminiscent of the Web 2.0 era. + +We are embarking on an ambitious mission to establish ourselves as a Polkadot and Kusama parachain. Our decision is anchored in several key reasons: + +First, we're enticed by their advanced interoperable features, such as shared security and XCM. These functionalities pave the way for seamless integrations with other projects within the ecosystem. We have already initiated talks with a few ecosystem teams like [Peaq](https://www.peaq.network/), [Tanssi](https://www.tanssi.network/), [Oak Network](https://oak.tech/) for potential integrations + +Second, the unparalleled ecosystem and technical support provided by Polkadot and Kusama have been instrumental in our development, and we've had the privilege of closely collaborating with them over the years. + +Lastly, the substrate framework stands out as the premier tool for crafting blockchains from the ground up in today's landscape. Our commitment to excellence aligns with the capabilities it offers. + +### Project Details + +#### Architecture: + +The core of our computing solution relies on both off-chain components and substrate pallets that work harmoniously with each other. + +Cyborg is a fusion of a blockchain network and numerous computing clusters, collaborating to offer an effective decentralized solution for verifiable off-chain computing. + +Our initial technological goal is to develop a system capable of validating computational outcomes from one off-chain cluster by re-executing them in another using pallet logic. + +![photo_2024-02-14_23-43-17](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/d50e7582-8f0f-461a-8668-10a828089404) + +The Substrate blockchain primarily serves as the framework for deploying containered tasks and facilitating smart contracts related to billing functions. + +Once the docker container is deployed, its workload will be protected by software based measures to prevent data leakage. + +It seamlessly integrates with the current cloud-native toolchain for developers, typically avoiding the need for code changes. + +Developers can monitor details such as resource utilization and application health status through the Cyborg Connect application dashboard. + +![dashboard](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/90f160c6-5cef-408b-8db2-c3e550fdb6a8) + +### Work Verification System + +For this grant application, we are developing a decentralized task verification mechanism to incorporate an on-chain validation system for containerized tasks executed in an off-chain environment. The main components will include the Cyborg AppChain, which will be deployed on Tanssi's Dancebox testnet, the client interface (K3s worker system), an Oracle, and a testing suite. + +![Screenshot 2024-02-15 at 1 09 56 PM](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/add65d92-0bf6-40df-a3fb-715fc0efce54) + +The objective is to upload a Docker configuration file and deploy the container inside one of the worker nodes of the K3s cluster. Before deploying the user's Docker image, the system will run a simulation to check for compilation failures or any startup runtime issues. If there are none, we will then proceed with the deployment. + +Deployment will follow this pattern: The system will submit the job to 'N' clusters, with 'N' being selectable by the user. However, we will set a minimum value for 'N' to ensure a baseline of accuracy and high fault tolerance. Users can increase the value of 'N' if they desire greater accuracy and fault tolerance. Among the chosen 'N' clusters, 40-50% will be highly trusted nodes, with the remainder being general/new nodes. This strategy ensures that customers receive a valid output. Despite this, the executed computation results will be pushed to the Oracle, which will then feed it to the Cyborg substrate chain. Subsequently, if the baseline accuracy is achieved, the result will be added to the block, and if the output does not match or there are deployment failures, the system will attempt to re-execute the job from the beginning, with a maximum of 'X' retries. The value of 'X' will be adjusted based on the cost calculations for each execution, which are yet to be determined. If the job continues to fail even after 'X' retries, the system will notify the user of the failure by providing detailed logs and request them to assess the reason for the failure. In case of deployment failures, we will assess whether the issue is due to missed edge cases, configuration issues, network instability, or hardware limitations. Based on this assessment, the system will reassign the job to different workers + +### Ecosystem Fit + +Cyborg Network augments the Polkadot ecosystem by ushering in decentralized edge computing, crucial for the growing demand of AI and IoT applications. By primarily catering to Web2 application providers, we're paving the way for a fresh wave of users to engage with the Polkadot ecosystem, fueling its expansion. + +Though Cyborg and the [Phala Network](https://phala.network/) share aspirations of decentralized computing within the Polkadot/Kusama environment, our technical paths and business aspirations are distinct. Phala Network provides off-chain compute infrastructure for smart contract-based applications by enabling users to integrate 'phat' contracts with their existing smart contract logic. While Cyborg is focused on creating utility for web2 applications. + +Another related project appears to be [Wetee](https://github.com/wetee-dao), which employs a comparable technical architecture utilizing TEEs to safeguard user privacy. However, their specific market focus is currently untraceable. We are developing products for a validated market that has already attracted interest from various AI applications and 50 small data center providers to join the network once it goes live. + +![Write here](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/a09109d1-e8f7-4ae5-8f4c-2eafc4b6ef6a) + +Our ultimate goal is to establish a decentralized edge computing network capable of executing targeted low-latency tasks to enhance system performance and efficiency. This approach aims to reduce the overall cloud footprint by providing an edge-to-cloud continuum, allowing users to augment our services with their existing cloud deployments. This, in turn, opens up new markets, particularly in real-time computation for edge AI and edge IoT devices. + +The technological landscape sees a plethora of competitors, each carving their niche with unique technical and market strategies. Renowned names include [Akash Network](https://akash.network/), and [Golem](https://www.golem.network/) . + +## Team :busts_in_silhouette: + +### Team members + +- [Barath Kanna](https://www.linkedin.com/in/barath-kanna) - Founder & CEO +- [Megha Varshini](https://www.linkedin.com/in/megha-varshini-t) - Founder & COO +- [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra) - Co-Founder & CIO +- [Ashi Mishra](https://www.linkedin.com/in/ashi-m-10a692273/) - Senior Substrate Developer +- [Dheeraj Reddy](https://www.linkedin.com/in/dheeraj-reddy/) - Rust Substrate Developer + +### Contact + +- **Contact Name:** Barath Kanna +- **Contact Email:** barathkannaofficial@gmail.com +- **Website:** https://cyborgnetwork.io + +### Legal Structure + +- **Registered Address:** 1111b South Governors Avenue, Dover, DE 19904 US +- **Registered Legal Entity:** ResoluteX Labs, Inc. + +### Team's experience + +- [Barath Kanna](https://www.linkedin.com/in/barath-kanna) - A developer with a specialization in Rust and blockchain technology. His experience is rooted in designing blockchain infrastructure solutions. Notably, he is an alumni of the Polkadot Blockchain Academy's third cohort at UC Berkeley (Jul - Aug 2023) + +- [Megha Varshini](https://www.linkedin.com/in/megha-varshini-tamilarasan-b1247a212) - She has been involved in operations for Web3 projects and has taken initiatives in the blockchain community. One of her contributions is the establishment of [Indi Verse DAO](https://www.linkedin.com/company/indi-verse-dao), a web 3.0 community in India. Additionally, she is the candidate of the Polkadot Ambassador Program. She is also a graduate from the Polkadot Blockchain Academy's Founders Track at Hong Kong (Jan - Feb 2024) + +- [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra) - With three years of work in Rust, Substrate, and INK, Kresna has a foundational background in blockchain solutions. He was the former co-founder and head of protocol development at [Invarch Network](https://invarch.network/) (Polkadot and Kusama parachain). Beyond this, he is also a Polkadot Ambassador who manages the Polkadot Hub in Bali. + +- [Ashi Mishra](https://www.linkedin.com/in/ashi-m-10a692273/) - A Senior Rust and Substrate Developer with experience working for projects like [Bitgreen](https://bitgreen.org/). + +- [Dheeraj Reddy](https://www.linkedin.com/in/dheeraj-reddy/) - Aspiring Rust systems engineer who is also a PBA alumni from Developer Track at Berkeley Cohort. + +### Team Code Repos + +Project GitHub repositories. + +- https://github.com/Cyborg-Network - Organization +- https://github.com/Cyborg-Network/cyborg-chain +- https://github.com/Cyborg-Network/Worker + +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/beekay2706 +- https://github.com/SHA888 +- https://github.com/ashi20192020 +- https://github.com/dheeraj07 +- https://github.com/Megha2712 + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/barath-kanna-23a23a172 +- https://www.linkedin.com/in/kresna-sucandra +- https://www.linkedin.com/in/megha-varshini-tamilarasan-b1247a212 + +## Development Status :open_book: + +We initially developed a Rust WebSocket client with a low-key profile, ensuring a seamless connection with our blockchain through off-chain workers. Additionally, we created a proof of concept based on this client. Our initial plan was to proceed with this development. However, based on the recommendation from the W3F grants team during our [previous application](https://github.com/w3f/Grants-Program/pull/1933) to eliminate centralized entities from our architecture and establish a fully decentralized system from the ground up, we embarked on several research iterations. + +Through this process, we identified the potential of using connected clusters than indivdual instances for better management efficiency, We are currently building an on chain work verification system. Our team will shift focus to building custom pallets outlined in the technical architecture to steer our way through to become a parachain on Kusama and eventually on Polkadot. + +As part of our transition, we are migrating from WebSockets to utilizing Libp2p as the core connection protocol. Furthermore, Subxt will serve as the standard communication protocol facilitating interaction between the Substrate chain and the off-chain domain. This strategic shift aligns with our commitment to adopting decentralized principles and enhancing the robustness of our system architecture. + +We have created a UX demo for a potential user and the development for this grant will look very similar to this [Cyborg Network UX demo](https://drive.google.com/file/d/1zrN4TRMDd5ON2xH9F00upcyK-3ofwV4r/view?usp=drivesdk) + + +## Development Roadmap :nut_and_bolt: + +We will be developing a PoC as a part for this grant. + +The goal is to achieve a functional system that is capable of scheduling and verifying a batch process (Shell Script or Docker container) that was executed in an off - chain entity. + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 2 ( 1 Full time Developers at 1 FTE/month and 2 part time developers each at 0.5 FTE/month) +- **Total Costs:** 10,000 USD + +### Milestone 1 - Task Verification System + +- **Estimated duration:** 2 months +- **FTE:** 4 +- **Costs:** 10,000 USD + +#### **Deliverables:** + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how users can (for example) deploy docker images using our interface. | +| **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. | Working Demo | We will provide video documentation to help developers understand the process of deploying containered tasks.| +| 2. | Task Examples | We will provide example containers and data sets to help programmers understand and execute batch processes. Currently we provide Examples for Docker, Bash, Terraform etc.. | +| 3. | Substrate Module: Verification | This pallet will be responsible for assign the task to a secondary cluster for result verification. Once verifed the accepted result will be added to the block. | +| 4. | Substrate Module: Edge Connect| This pallet will posses the logic for schedluing tasks to a specific cluster that matches the required specifications| +| 5. | Worker K8S Operator | The k8s worker acts as a trusted controller. It securely stores deployment states, including manifests and defined secrets. Based on the manifests, the Worker uses remote attestation to authenticate the task exceution process.. | +| 6. | Worker logs | The execution logs of the deployed container to serve as a proof of work. | + +## Future Plans + +- **Short term plans:** We intend to use the grant to develop the core functionality of Cyborg Network and also be encouraged to develop this product further to an MVP that can address latency issues in applications that work on real time data processing. +- **Long term plans:** We intend to build Cyborg Network into a comprehensive decentralized edge computing network, thereby unlocking novel markets, especially in real-time data management for edgeAI and edge IoT devices. We also plan to support additional features like edge server monetization, server hardware management and upgrades over time. + +## Additional Information :heavy_plus_sign: + +Cyborg Network was a part of the [Polkadot Relayers Incubator 2023](https://www.polkadotglobalseries.com/incubator/) and [Polkadot Encode Accelerator 2023](https://www.encode.club/encode-polkadot-accelerator-2023). + +We won the [web3hackx](https://www.hkweb3month.com/hackathon) Hackathon - Hong Kong (Nov 2023) in the Infrastructure track and Polkadot Bounty. + +Megha Varshini (COO) - represented Cyborg Network at the Finals (Top 7 teams) of the PBA pitch Contest in Hong Kong (Feb 2024) + +Kresna (CTO) has also contributed to the **InvArch's Web3 Foundation Grant** [Milestone 1](https://github.com/w3f/Grant-Milestone-Delivery/blob/7932b07cc38150701ba8ed034723193f66002975/deliveries/InvArch_M1.md) that has been completed successfully. He also contributed to the [Chocolate Network](https://substrate.io/ecosystem/projects/chocolate/) as a Substrate developer for their Substrate Builder Program (SBP) Milestone 1 delivery which has been completed successfully. + +Cyborg Network has been inducted into the [Polkadot Alpha Builder's Program](https://polkadot.network/development/alpha/) in March 2024. diff --git a/applications/DAOsign.md b/applications/DAOsign.md new file mode 100644 index 00000000000..bcfee2b6f94 --- /dev/null +++ b/applications/DAOsign.md @@ -0,0 +1,243 @@ +# DAOsign + +- **Team Name:** DAOsign +- **Payment Address:** 13s3c37rwrZfa8WQcZPdqE1zi1hGAguf2TWfWMr8f5aLBrg +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + + +### Overview + +DAOsign is a decentralized platform for agreements and policies with publicly verifiable and authorized cryptographic proofs and Governance Automation, designed for DAOs. +Traditional methods of signing agreements, such as paper-based systems or legacy e-signatures, are prone to fraud and lack transparency, and offer no solution for verification of the signer's identity or signer’s authority to execute the agreement. Instead these systems rely on costly legal proceedings for enforce agreements. + +DAOsign provides publicly verifiable cryptographic proofs; secure, transparent and automated processing of complex Agreements and Policies. + +Furthermore, DAOsign provides robust Governance and Policy Builder platform to provide governance, workflow automation and controls for organization policies and procedures. + +### Project Details +A project goal is to store Agreements Proofs on Polkadot chain using Ink! smart contracts. + + +Deliveries include DAOsign platform with an ability to: +- create agreements including generating using ChatGPT (already implemented on our platform, currently available on our [testnet](https://testnet.daosign.org/) +- add and remove signers and observers of different levels of anonymity +- allow signing the documents with further storing of signature proofs on Astar testnet blockchain. + + +**Core DAOsign components** + +Screenshot 2023-05-27 at 16 51 43 + + +**Technical design** + +Proofs are implemented in the EIP-712 standard and adjusted to ink! ecosystem. Proofs digned using user’s EVM private key. +We are supporting this standard in Ink! smart contract to be able to verify the signature in ink! smart contract. +Also, we are implementing an adjusted EIP-2771 standard to allow Agreement Signers gas-free delegation to publish proof on-chain. +EIP-712 standard will be used for proofs, adaptation means that user data is converted to a binary bit; we use its hash (serialization vs deserialization) +And EIP-2771 standard - to securely send the proof and receive it. +So that EVM standards will be adapted to ink! ecosystem requirements. +Example (interfaces) of the smart contracts can be found here https://github.com/DAOsign/daosign-smart-contracts (Solidity version). + + +Detailed storyboard can be found here: https://consideritdone.storiesonboard.com/m/PUCLDvQC4kKwoRJ8kbm3MA . + +**Off-chain Relayer** + +Relayer is an off-chain component that accepts transaction (with EIP-712 signature from Metamask) from user, +signs it and sends to the network. This app will be developed using following technology stack: + +* Typescript/NodeJS +* express.js +* polkadot.js + +**Architectural diagram** + +![DAOsign_ Storing proofs using Ink!](https://github.com/Burmenska/Grants-Program/assets/1008882/297093a0-200a-4f78-babb-04ad6314fb35) + +**Definitions**: +* **Creator**: Author of agreement, define agreement content, signers +* **Signer**: Participant (Signer) of the agreement. Signs and sends transactions to a Relay +* **Relayer**: Receives signed requests off-chain from Signers and pays gas to turn it into a valid transaction that goes through a Trusted Forwarder +* **Trusted Forwarder**: A contract trusted by the Recipient to correctly verify signatures before forwarding the request from Signers +* **AgreementProof**: A contract that holds metadata and proofs for agreement.er + + +Agreement Proof entity represent 3 proofs: +* Proof of signature +* Proof of authority +* Proof of agreement + +The detailed Proof Technical Design is [here](https://github.com/w3f/Grants-Program/files/12183424/Proofs.Technical.Design.-.DAOSign.pdf) + +**UI Design** + +In Milestone 2 we have a frontend delivery. Here list of wireframes/designs with comments: + + +1. Adding toggle to allow store Agreement Proof on-chain (toggle above Sign Agreement button) +![Store proofs 0](https://github.com/w3f/Grants-Program/assets/1008882/40f89bfa-50fc-4944-8a64-af84337b713a) + +2. Enable that toggle and select Parity network from dropdown + +![Store proofs 1](https://github.com/w3f/Grants-Program/assets/1008882/87894c58-bc30-4e48-b74b-3eabfcad2779) + +3. After user click `Sign Agreement` and execute transaction, we show `On-chain Proof` transaction hash on Information panel +![Store proofs 6](https://github.com/w3f/Grants-Program/assets/1008882/88dfed66-5f88-4658-88b4-8a6198060de9) + + +### Ecosystem Fit + +DAOsign fit the Governance category and since, Polkadot and Kusama are designed to be community-driven networks that allow for decentralized governance. DAOsign can fit into this ecosystem by providing a platform for DAOs to manage their decision-making processes in a decentralized manner. +Our target audience is not only DAOs, but also all the companies, who have a need to deal with the agreement/policies management including the use case for managing Grants, that was presented to you during our introdution call. +Competitors analysis can be found here: https://docsend.com/view/sbexkxn5su3ahdg8 . Particularly in Substrate / Polkadot / Kusama ecosystems we are not aware about any tools, that provide exactly the same functionality. + + +## Team :busts_in_silhouette: + +### Team members + +- Team Leader, Founder: Eugene Fine https://github.com/ConsiderItDone, +- Solution Architect: Ramil Amerzyanov https://github.com/ramilexe +- Blockchain / Tech lead: Misha Kushka https://github.com/kushkamisha +- Director of Buisiness development and Partnerships: Oleksandra Burmenska https://github.com/burmenska + + + +### Contact + +- **Contact Name:** Eugene Fine +- **Contact Email:** eugene@daosign.org +- **Website:** daosign.org + +### Legal Structure + +- **Registered Address:** 2468 Brian Dr. Northbrook, IL 60062 +- **Registered Legal Entity:** DAOSIGN, LLC + +### Team's experience +**Eugene Fine:** CEO, Founder +Background: +Over 20 years of building, scaling, and managing technology organizations. Past experience: +- CTO for https://www.explorersurgical.com +- tech leadership contribution to https://bird.coach +- tech advisor and facilitator for polywrap.io +to name a few. +Also, Eugene is a founder at consideritdone.tech and daosign.org + +**Ramil Amerzyanov:** Solution Architect, CTO +Background: +12+ years in building complex enterprize solutions (all SDLC aspects), including 7+ years in Blockchain industry. +Past projects include: +- contribution to Ethereum standards development +- tech leadership for https://docsend.com/view/fjrvjtyzgm7wgrkj projects + +**Oleksandra Burmenska:** Director of Business Development and Partnerships +Background: +Engineering, MBA, and Psychology diplomas. Over a decade of experience in IT: development and managerial positions, last five years focused on the Blockchain industry. +Experience with enterprises and startup companies, scaling teams, and building blockchain products. +Previous blockchain projects include: +- successfully managed ICOs during 2017-2019 (example: Õpet – Medium ) +- contribution to Polywrap, NEAR, Axelar, GnosisSafe, Avalanche ecosystems +- contribution to nodle.com ecosystem: managing the block explorer development (before it moved to Subscan), leading the Landslide - Avalanche subnet development,etc. + +**Misha Kushka**: Tech Lead and Blockchain Developer +Background: 6+ years of professional experience as a developer, 4+ years of professional experience in the Blockchain field, 4+ years experience as a lead + +### Team Code Repos + +- https://github.com/ConsiderItDone +- https://github.com/DAOsign + +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. + +- [Eugene Fine](https://github.com/ConsiderItDone) +- [Ramil Amerzyanov](https://github.com/ramilexe) +- [Oleksandra Burmenska](https://github.com/Burmenska) +- [Misha Kushka](https://github.com/kushkamisha) + +### Team LinkedIn Profiles (if available) + +- [Eugene Fine](https://www.linkedin.com/in/eugenefine/) +- [Ramil Amerzyanov](https://www.linkedin.com/in/ramil-amerzyanov/) +- [Oleksandra Burmenska](https://www.linkedin.com/in/oleksandra-burmenska/) +- [Misha Kushka](https://www.linkedin.com/in/mkushka/) + + +## Development Status :open_book: + +We are currently working on a tech demo (kind of a pre-beta version) and non-blockchain version of DAOsign is available here: https://testnet.daosign.org + +## Development Roadmap :nut_and_bolt: + +## Overview + +* **Total Estimated Duration:** 2 months +* **Full-Time Equivalent (FTE):** 2 FTE +* **Total Costs:** 48,100 USD + +### Milestone 1 - Smart Contract Development + +* **Estimated Duration:** 4 weeks +* **FTE:** 2 +* **Costs:** 24,050 USD + + +| Number | Deliverable | Specification | +|-------:|---------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can use DAOsign Smart Contract developed in ink! for proof verification. | +| 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 as part of the grant. And we will publish a series of articles that explains how DAOsign works from a high-level perspective. The content of the articles will be consistent with the functions at this stage. | +| 1. | Smart Contracts | DAOsign Smart Contract repo that includes following components: Agreement Contract, EIP712/EIP2771 standard implementation on Ink!. These smart contracts can be deployed to any substrate chain with contracts-pallet. | | + + +### Milestone 2 - DAOsign Application integration + +* **Estimated Duration:** 2 weeks +* **FTE:** 2 +* **Costs:** 12,025 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 | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. | +| 0d. | Docker | Dockerfile(s) provided in Milestone 1 will be used to test all the functionality delivered with this milestone. | +| 1. | DAOsign Ink! JS SDK | We will publish a npm/yarn package with the logic how to interact with Smart Contract from JS | +| 2. | DAOsign Application Integration | Integrate DAOsign application using SDK. DAOsign application (which is not part of this grant) will be open sourced as well. DAOsign is written using ReactJS on frontend and Typescript on backend | + + +### Milestone 3 - Relayer Development + +* **Estimated Duration:** 2 weeks +* **FTE:** 2 +* **Costs:** 12,025 USD + + +| Number | Deliverable | Specification | +|-------:|---------------|------------------------------------------------------------------------------------------------------------------------------------------------| +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can run Relayer and broadcast transactions | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Gas Relayer | Off-chain component for relaying transactions. Will be developed on Typescript/NodeJS using polkadot.js library | + + + +## Future Plans + +After the `ink!` version of the DAOsign protocol stack is fully tested, we would like to implement a `pallet` version for Polkadot ecosystems. Anyone who is integrating it can communicate with other ecosystems conveniently. + +Add support for multi-chain proof verification using [XCM](https://wiki.polkadot.network/docs/learn-xcm) and [IBC](https://ibcprotocol.org/) protocols. + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +By recommendation of Richard Casey from Parity. diff --git a/applications/DIA_Bridge_Attestation_Oracle.md b/applications/DIA_Bridge_Attestation_Oracle.md new file mode 100644 index 00000000000..966dfc3256f --- /dev/null +++ b/applications/DIA_Bridge_Attestation_Oracle.md @@ -0,0 +1,273 @@ +# Bridges Attestation Oracle + +- **Team Name:** DIA Data +- **Payment Address:** 0xC13233bd20a7FcB1d7c2394AdE4857b778382264 Ethereum. Preferred currency - USDC (0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48). +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +Decentralized, on-chain bridge attestation oracle for Polkadot using off-chain workers + +Over the last few years, bridges have been the target of a number of high profile hacks. According to the [rekt.news](https://rekt.news/leaderboard/) 'hack leaderboard', 4 of the top 5 hacks in terms of USD value lost were attacks on bridges (total $2.2 billion lost amongst these 4 hacks). Despite many efforts to develop more robust and secure bridge architectures, there is no industry-wide tooling available for protocols to bolster their security in case a bridge is hacked. This is why we aim to to develop a decentralised, real-time bridge status update oracle that will help protocols in the Polkadot ecosystem protect their operations and customer funds. + +![Bridge Attestaion Oracle Solution Overview](https://user-images.githubusercontent.com/103409771/224655563-dbd6dca4-839d-41a5-859e-fa74c8868f84.png "Attestation oracle architecture") + +Our approach is to introduce on-chain verification of bridge balances on the Polkadot network using off-chain workers. The main idea behind this is that all dapps operating on Polkadot parachains will be able to integrate this security module, enabling them to trigger automated precautionary notifications and actions in case bridge balances unexpectedly drop. We achieve this by tracking bridges' locked asset vs issued assets across multiple chains. This allows us to calculate a collateral ratio, which protocols can use to define and trigger safety procedures in their code when the specified conditions are met. + +The DIA team has already gained experience with collateral ratios, while creating fair value price feeds for Liquid Staked Tokens in the Polkadot ecosystem and beyond (more info [here](https://www.diadata.org/xlsd-liquid-staking-oracle/)). The bridge attestation oracle would be specifically designed for use in the Polkadot ecosystem. Being a crosschain oracle by nature, we perceive a significant benefit in the proposed solution, because using the collateral ratio in the determination of asset prices that use bridges to bring liquidity to multiple blockchains enables the calculation of fair value prices. + +### Project Details + +#### Architecture overview + +The proposed project consists of a few core components that are to be developed. + +First, an overview regarding the data structures needed to represent bridge states: + +``` +Asset: + Address string + Chain string + Decimals uint + Symbol string + Name string + +BridgeSet: + LockedAssets []Asset + MintedAsset Asset + LockedAmounts []uint + MintedAmount uint + +Bridge: + Sets []BridgeSet +``` + +Note that `BridgeSet` is directional, so a bridge can hold a set twice in both directions if needed. By that, we can track minted and locked pairs in an omnidirectional way. Also note, that a `BridgeSet` mints one token but can access several locked assets on different source chains. + +With these in mind, the following components are proposed: + +1. An off-chain worker which reads bridge states: This component is used as an adapter between bridge states and the target parachain. It is used to read the amounts of locked assets from specified addresses (the bridge reserve addresses). +2. A token identification system which identifies matching tokens across multiple chains (i.e. both sides of each bridged asset). Identification requires that for an asset at least the chain and the address are defined. + +An example flow on the token identification within the proposed system could look like this: +1. Read bridge-locked tokens on multiple source blockchains with RPC calls. +2. Compute total amount of locked tokens by adding the values from the previous calls. +3. Determine the amount of issued tokens on the target network. +4. Perform calculation `MintedAmount - Sum([]LockedAmounts)`. +5. Output values of number of issued tokens, number of locked tokens and collateral ratio values. + +All components will be available open-source to enable access to any dapp/protocol that intends to integrate this or further develop the components. +Also, a standard format (similar to the defined data structures above) will be developed to facilitate integrations of future bridges. + +#### Technology stack + +- Pallet & off-chain workers will be the main enabler of the entire solution, reflecting Polkadot's native feature of off-chain workers integrated with pallets. + - Rust programming language will be used to develop the pallet and the off-chain worker. +- RPCs will be the main gateway for querying data from different chains. As RPCs represent single points of failure, they will be implemented using the following logic: + - Only publicly available RPCs will be used to circumvent private key management hurdles for publicly accessible solutions. If technically possible, we would enable the pallet integrator to choose their own private RPCs, if they prefer this. + - We will set-up a back-up system of at least 2 additional public RPCs in case one RPCs fails. + - We will set-up backstops for generating collateral value in case at least one of the RPCs fail. + +Hosting and infrastructure will be organized as follows: + +The main repository will be available on Github. Pre-built instances of our container images will live in Docker Hub for everyone to download. We seek to implement a CI/CD system that automatically builds and publishes latest changes so that anyone can use the latest version with ease and integrate fetching the latest version in their automation flow as well. Due to the decentralized nature of the proposed architecture, only the token identification data needs to be hosted centrally. For that, we will either extend existing community directories or build our own, with hosting the resulting identification files on github as well. + +We will also host documentation on how to use and participate in the system. + +#### MVP + +Our MVP will consist of four main parts: +1. The pallet providing collateral value that can be integrated by parachains +2. The documentation of integration +3. Integration of 2 bridges +4. Guidelines on integrating new bridges + +#### Expectations + +Team DIA will: +- Create the framework and open-source the library of this integration. +- Integrate 2 bridges for initial use. Further integrations will be open for submissions from contributors. + +We will not: +- Cover a security audit as a part of MVP design. + +### Ecosystem Fit (Requirements) + +#### Overview + +The Polkadot ecosystem is a natural fit for this solution for several reasons: +- Polkadot is a network of numerous parachains which utilize XCM for trustless and secure communication without relying on bridges. However, to achieve the vision of interoperability with external chains, bridge monitoring and attestation are necessary to establish trust and ensure the integrity of the transactions between the networks. +- The entire architecture of the product is tailored specifically to the Polkadot ecosystem due to it's unique ability of executing computational programs via off-chain workers. +- The tool adds significant value for a variety of Polkadot ecosystem actors - parachains, dapps, bridges, oracles and others. +- The tool aims to serve as a public good on Polkadot, therefore will benefit anyone that integrates it. + +#### Target audience + +We have identified our target audience as follows: +- Parachains are the target facilitator that will enable the adoption, but they also stand to benefit from integration themselves as the tool enables them to track bridges' security on a chain level. +- DeFi dapp developers (e.g., lending protocols) are the main beneficiaries. We expect to see most adoption from them, as they are the arbiters that enable bridged assets to be traded/staked or used however else and thus are most directly exposing their users' assets to these risks. +- Bridges can integrate the security module to create their own security processes. They will strongly benefit from having an independent third party tracker next to their own internal ones. +- Oracles will be able to use the collateral ratio for interchain asset pricing. In theory, native asset trading statistics can be bridged to synthetic asset in order to decrease manipulation risk. +- As the module will be fully open source, any other Polkadot ecosystem developer/team can integrate it for their use cases. + +#### Meeting the needs + +Bridge hacks are rare but painful because of the potentially high amount of funds that are constantly at risk / an attractive target for malicious actors. Therefore, the bridge attestation oracle will provide a live auditing tool for any actor in the Polkadot ecosystem that wants to make their operation more secure. + +In discussions with various ecosystem actors, the idea and architecture of the solution were presented with the goal of validating the problem and the potential solution. We received supportive feedback from all interviewees, and therefore decided to pursue the inititive further. + +To verify the relevance of the idea we conducted interviews with several ecosystem participants, including + +- Acala +- Astar +- AstridDAO +- Interlay +- Pendulum +- StellaSwap + + +#### Similar projects + +We were not able to identify any similar solution present in the market. Similar approaches can be attributed to: +1. Proof of Reserves oracles - developed by several oracle providers, these oracles track the amount of tokens in reserves and provide this information publicly. +2. Cross-chain messaging protocols - these have architectural similarity in that one could transmit bridge balances as a message, however there are several limitations to this approach: + - They would act as a 2nd layer bridge (bridge for bridge balances) and are also prone to manipulation. + - Gas fees would have to be paid on the origin chain, which causes potentially volatile costs required to run such operation, putting them at risk. +3. Real time alert providers for smart contract activities. Tools such as [Forta](https://explorer.forta.network/) allow to set-up monitoring and notifications for pre-determined smart contract activities. However, they do not offer a direct solution for bridge balance monitoring, which we aim to deliver. + +As our proposed solution is different in nature, we do not perceive any of the existing approaches as real alternatives. Additionally, all of these solutions are commercially driven, while the bridge attestation oracle will serve as a public good. + +#### Risks + +- RPC manipulation risk - the solution will use RPC services to retrieve data from blockchains. Therefore, if someone manages to manipulate RPC data, the final value could be exploited. A potential mitigation could be to introduce connections to multiple RPCs simultaneously to reach a consensus. +- Contract migration risk - from time to time protocols may need to migrate or upgrade contracts. This could produce incosistent values. To avoid this, direct communication channels with bridges can be set up and tracked to flag any changes on the smart contract level. This could be complemented with community based forum where contributors could also flag these migrations manually. +- Off-chain worker operational risk - the solution is developed on the assumption that off-chain workers can be trusted and will be maintained within the Polkadot ecosystem. However, upgrades, malfunctions or the unlikely event of discontinuation of off-chain workers poses a risk to the solution. In this case, migration to another off-chain computation platform could be a mitigation (e.g. Phala or Integritee). + + +## Team :busts_in_silhouette: + +### Team + +- Samuel Brack // Cofounder and CTO at DIA // [Github](https://github.com/kaythxbye) // [LinkedIn](https://www.linkedin.com/in/samuelbrack/) +- Philipp Pade // Lead Integrations Developer at DIA // [Github](https://github.com/jppade) // [LinkedIn](https://www.linkedin.com/in/jan-philipp-pade/) +- Nitin Gurbani // Senior Developer at DIA // [Github](https://github.com/nnn-gif) // [LinkedIn](https://www.linkedin.com/in/nitin-g-098229228/) +- Zygis Marazas // Product Lead at DIA // [LinkedIn](https://www.linkedin.com/in/zygimantas-marazas/) +- Paul Claudius // Cofounder and Business Development Lead at DIA // [LinkedIn](https://www.linkedin.com/in/paulclaudius/) +- Dillon Hanson // Business Development Manager at DIA // [LinkedIn](https://www.linkedin.com/in/dillonhanson/) + + +### Contact + +- _**Contact Name:** Paul Claudius +- _**Contact Email:** paul.claudius@diadata.org +- _**Website:** https://www.diadata.org/ + +### Legal Structure + +- _**Registered Address:** Baarerstrasse 10, 6300 Zug, Switzerland. +- _**Registered Legal Entity:** DIA e.V. + +### Team's experience + +Experience which will help to succesfully develop this project is listed below: + +#### Development of a pallet for oracles + +Team DIA has extensive experience in developing a pallet for Polkadot using off-chain workers. The pallet was developed to serve the purpose of accessing oracles natively by parachains. The documentation of the solution can be found [here](https://docs.diadata.org/documentation/oracle-documentation/oracle-structure/polkadot-offchain-worker). + +#### Scraping Multichain bridge + +Team DIA already did experiments with automatic bridged assets identification, therefore we already developed a [Multichain](https://multichain.xyz/) bridge scraper which maps out assets accross a variety of chains. + +#### Development of collateral based values for nASTR, iBTC, stDOT, stETH, rETH, vKSM, kBTC + +We recently launched xLSD - a product that tracks collateral values for liquid staked tokens + +#### Established partnerships in oracle fields with Polkadot ecosystem parachains + +We are already present in the Polkadot ecosystem and have developed oracles for a range of parachains and dapps, and integrated natively with a range of DEXs including: + +- Moonbeam & Moonriver + - Midas Capital + - Mixbytes + - Orbiter One + - Raze Network +- Astar + - Starlay + - SIO2 Finance + - Algem + - AstridDAO + - Orcus Finance + - Starfish Finance + - Rikkei Finance + - Arka Finance + - Standard Protocol +- Pendulum +- Interlay +- Bifrost + +DEX integrations: +- Beamswap (Moonbeam) +- Stellaswap (Moonbeam) +- Arthswap (Astar) +- Huckleberry (Moonriver) +- Solarbeam (Moonriver) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 1.5 FTE +- **Total Costs:** 26,000 USD + +### Milestone 1 - Core functionality + +- **Estimated duration:** 1.5 months +- **FTE:** 1.5 +- **Costs:** 18,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 intgrate the collateral value into their code, which will display the functionality. | +| **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 introduces to the solution with all the guidelines included. | +| 1. | Attestation oracle core: Off-chain worker | We will create an Off-chain worker as stated in the architecture overview section. | +| 2. | Attestation oracle core: Pallet | The entire solution will be made available as Pallet (described in architecture section). | +| 3. | Attestation oracle core: RPCs | We will set-up connections to RPCs of other chains with fallback functionality (at least 2 RPCs per chain). | +| 4. | Attestation oracle core: Collateral ratio calculation | The logic for calculating collateral ratio will be developed within the off-chain worker. | + + +### Milestone 2 — Bridge integrations + +- **Estimated Duration:** 1.5 months +- **FTE:** 1 +- **Costs:** 8,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can integrate bridges collateralization value, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Bridge Integration: Multichain | We will develop a module as part of the proposed solution that retrieves collateral information for assets bridged by the [Multichain bridge contracts](https://github.com/anyswap). | +| 2. | Bridge Integration: Interlay | We will develop a module as part of the proposed solution that retrieves collateral information for assets bridged by the [Interlay bridge contracts](https://github.com/interlay/interbtc). | + + +## Future Plans + +We see a lot of potential for the future of the solution, these include: +- Develop attestation for multichain Liquid Staked Tokens (e.g. aUSD). +- Spin-off as independent solution (not a pallet). +- Develop monitoring dashboards for researchers. +- Create built-in notifications services. +- Expand into any smart contract metrics tracking that allows users to define their own logic. +- Introduce community driven governance for any changes and future directions of the solution. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** - personal recommendation diff --git a/applications/DICO.md b/applications/DICO.md index 1495294cbc5..70aaa4e91cb 100644 --- a/applications/DICO.md +++ b/applications/DICO.md @@ -1,12 +1,9 @@ -# DICO Open Grant Proposal +# DICO - -* **Project Name:** DICO * **Team Name:** DICO Team * **Payment Address:** 0x0211ae8881a3a0a41150627da07c900b78144a84(USDT) * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/636#issuecomment-1144901144) - ## Project Overview The `DICO` is to create a decentralized and governable ICO platform for the Polkadot/Kusama ecology. Our platform will allow entrepreneurs to quickly find investors. In a word: Be a platform to link ideas and capital. @@ -26,24 +23,20 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy * *KYC*,*ICO*,*DAO* and *Swap* modules are built on substrate runtime. they complete the basic user interaction logic. * *Oracle* enabled off-chain worker to query the current price feed of the platform or other tokens. - ### Project Details #### Mockups and UI components -

- #### ICO

-

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

-

- #### KYC

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

- #### DAO

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

- #### Swap -

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

- ### Ecosystem Fit * Where and how does your project fit into the ecosystem? @@ -118,7 +105,6 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy > Be a platform to link ideas and capital. - * Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? * If so, how is your project different? *coinlist*，A token financing platform, all the mainstream virtual currencies above can be traded and financed. It provides token financing, but does not provide the funds needed by early creator and the control of the entire project cycle. @@ -147,11 +133,11 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy ### Team's experience -*Daniel*: Daniel is currently a venture investor at [WEB3 Venture Capital](https://web3.vc/#/). Daniel previously is a solidity/EOS engineer. +*Daniel*: Daniel is currently a venture investor at [WEB3 Venture Capital](https://web3.vc/#/). Daniel previously is a solidity/EOS engineer. *gogomath*: gogomath is the CTO of the team and has 10 years of software development experience. The fields involved are big data, machine learning, SAAS, devops. And familiar with eth/near/polkadot in the field of digital encryption development. -*cf*: cf is a full stack engineer with five years of development experience. and familiar with Go/Rust/Java/Python/Javascript/Typescript +*cf*: cf is a full stack engineer with five years of development experience. and familiar with Go/Rust/Java/Python/Javascript/Typescript *tokggo*: tokggo is the test/devops engineer of the team, he is very good at writing various documents.and has 6 years of development experience. @@ -163,23 +149,18 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy * https://github.com/DICO-TEAM/dico-chain - ## Development Status :open_book: - *interface iterations and resource*: https://github.com/DICO-TEAM/resources ## Development Roadmap :nut_and_bolt: - ### Overview - * **Total Estimated Duration:** 1 months * **Full-Time Equivalent (FTE):** 6 FTE * **Total Costs:** 10k USD - ### Milestone 1 — Implement KYC, ICO, DAO Modules * **Estimated duration:** 1 month @@ -192,9 +173,9 @@ Our project use substrate framework and is built on top of Polkadot/Kusama ecosy | 1.a | Substrate module: KYC pallet | KYC pallet Includes identity authentication service(IAS), KYC users, and swordholder. responsible for providing users with a decentralized KYC certification service.and provide area authentication of the account.Detailed explanation is described [here](https://github.com/DICO-TEAM/dico-chain/tree/main/pallets/kyc/README.md)| | 1.b | Substrate module: ICO pallet | Apply for ICO and council review for the project party. Detailed explanation is described [here](https://github.com/DICO-TEAM/dico-chain/tree/main/pallets/ico/README.md)| | 1.c | Substrate module: DAO pallet | Integrate governance with the ICO module to provide governance logic for the opening and closing of the ICO of the project. Detailed explanation is described [here](https://github.com/DICO-TEAM/dico-chain/tree/main/pallets/dao/README.md)| -| 2.a. | Integration with front-end(dapp) |integrate our existing front end to the finalized module.| +| 2.a. | Integration with front-end(dapp) |integrate our existing front end to the finalized module.| | 2.b | Tutorial| We will create an screenshot tutorial and a demo video that will explain how users can start using the platform for KYC and ICO. | -| 3. | Testing Guide/Documentation | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests and add inline documentation of the code. | +| 3. | Testing Guide/Documentation | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests and add inline documentation of the code. | | 4. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.| | 5. | Docker-compose | We will provide a docker-compse.yml that can be used to test parachain version node delivered with this milestone.in this version, users will be invited to this testnet | -| 6. | Lending module(research oriented)| Innovation combining ICO and borrowing/lending. In our 2.0 version, we hope to introduce an innovation combining lending and ICO. The goal is to make ICO more diversified through borrowing/lending. Through the logic of borrowing/lending, and participation in ICO, the participants will be more diverse. At the same time, in the 2.0 testnet, we will let users participate in this pallet. According to the test results, publish a blog to show the test results.| +| 6. | Lending module(research oriented)| Innovation combining ICO and borrowing/lending. In our 2.0 version, we hope to introduce an innovation combining lending and ICO. The goal is to make ICO more diversified through borrowing/lending. Through the logic of borrowing/lending, and participation in ICO, the participants will be more diverse. At the same time, in the 2.0 testnet, we will let users participate in this pallet. According to the test results, publish a blog to show the test results.| diff --git a/applications/DINFRA.md b/applications/DINFRA.md new file mode 100644 index 00000000000..4d2fd0941d9 --- /dev/null +++ b/applications/DINFRA.md @@ -0,0 +1,214 @@ +# DINFRA + +- **Team Name:** Valletech AB +- **Payment Address:** FIAT +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + + +### Overview + +DINFRA, decentralized infrastructure, is substrate orchestrated infrastructure, a decentralized alternative to public clouds. + +Substrate allows us to create a specialized blockchain, which we see as the perfect blending between Custom Functionality, Decentralized Governance and Value/State tracking. + +Modern data-center technology is now software defined, API driven and hyper-convergent with capability to virtualize Compute, Storage and Networking. Specialized network equipment is being replaced by virtualized services. There is also great availability of Open Source technologies covering all aspects of the modern data center. + +DINFRA aims to create a Substrate blockchain to orchestrate hyperconvergence infrastructure in a democratic, decentralized, open/neutral and non technically opinionated way. + +Realizing DINFRA vision requires a viable strategy. This project represents the first phase of a three phase strategy in which an Open Source Minimum Viable Product is delivered for the purpose of developing, testing, generating awareness and gaining community support. + +After delivering [Polkawatch](https://blog.polkawatch.app/introducing-polkawatch/), our analytic engine to measure decentralization of the substrate validation process, DINFRA is the natural next step for us to take in the Substrate Ecosystem. We have a track record contributing to Cloud automation stacks, we created [Privazio](https://www.privaz.io/) for small organizations to be able to fully automate their infrastructure and have used it to deliver Polkawatch for Polkadot and Kusama. We would like to start contributing to effective substrate infrastructure decentralization next. + +For a complete presentation of DINFRA vision and strategy see this [Video Presentation](https://vimeo.com/800524188). + +### Project Details + +**Design Constraints** + +We gave been part of the Dotsama community and that has allowed us to gain a better understanding of how it operates. Consequently, some key decisions have been taken that impact our choices of design and architecture: + +* DINFRA must be open and non technically opinionated. Infrastructure providers must be able to offer their solutions via DINFRA without being forced into specific technologies or opinionated solutions. Furthermore, they should be able to offer their current infrastructure via DINFRA provided they have industry standard automation capabilities, which typically they do, with minimal effort. +* DINFRA must be decentralized and democratic adopting and following the practices that we see on Kusama and Polkadot for governance. +* DINFRA must focus on the needs of our ecosystem first. + +We consider these points a prerequisite for community acceptance and adoption. + +**Design Interfaces and Data Modeling** + +DINFRA main responsibility will be to mediate between consumers and providers awarding "deployment descriptors" to "infrastructure providers" by means of consensus, collect balances accordingly, etc. + +From the previous constraints we deduce that we need lose typing of deployments descriptors, and DINFRA being able to distribute descriptors as opaque entities which don't need to be fully understood. + +Infrastructure Providers should be able to self register on DINFRA with information about which types of descriptors they can serve, even register new types of Deployment Descriptors for their flavored solutions if they happen to have some differential in-house capability. + +Deployment Descriptors will be able to represent things as diverse as a Helm Chart, Docker Compose, Cloud-Init user data, Subquery Project descriptor or IPFS cluster member profile. As long as each Provider registers their deployment capabilities properly, DINFRA must be able to route deployment requests to them. + +Deployment descriptors will be specified in JSON with its type defined as a JSON Schema. This provides loose typing and flexibility to accommodate any deployment descriptor possible, besides the fact that JSON/YAML is a widely used already by most infrastructure platforms and solutions. + +Note that Deployment descriptors won't be stored on chain but preimaged and backed on IPFS, as they are required during deployment. Secrets, whenever possible should be deduced from on-chain data preferably in the form of public keys. + +**High Level Architecture** + +DINFRA Architectural stack resembles pretty much a substrate stack under an infrastructure automation stack, like this: + +![DinfraHLArch](https://user-images.githubusercontent.com/412837/225624664-f7cf0074-5fbd-4078-bd30-374b5e89ea42.png) + + +We make the active choice of not connecting infrastructure platform / automation stack directly to the blockchain, for example via its Offchain Worker Interface, but we introduce an intermediate component called "Chain Reactor." + +The Chain Reactor is responsible for orchestrating infrastructure according to decisions taken on chain. The most prominent actions would be to deploy infrastructure as a descriptor is awarded or tear down infrastructure as a deployment reaches its termination. + +In order to fulfill the constraints above, Chain Reactors must be easy to implement using any infrastructure automation stack on any suitable language, and it must be simple to do so. Whether Python/Ansible, Java/Cloustack, Go/Terraform, Go/Helm, Python/Juju, etc. Chain Reactors must rely on programming language-agnostic API specifications/tooling such as OpenAPI/swagger for generating stubs in any language that can be used as base for implementation. + +**Technology Stack Used** + +In line with the strategy decided above, this project will focus on a minimal viable product while honoring the constraints and architecture above. + +The components generated must also serve as "Reference Implementation" to community members willing to generate similar implementations for other infrastructure platforms or solutions. + +The Stack for the current MVP will be made of: + +- Apache CloudStack: As Infrastructure Platform +- Ansible / Python: As tooling for implementing a Chain Reactor. +- Substrate: For DINFRA Parachain +- Gitlab CD/CI: For Reference Implementation of Automated Testing and CI/CD. +- Docker Compose: For rapid development setup. +- Gitlab CD/CI: for End to end Itegration testing, to avoid regression when new Apache CloudStack versions are released. + + +**Scope** + +Lots of the features that we pitch in our DINFRA [video presentation](https://vimeo.com/800524188) are left out of the scope of this phase. DINFRA opens a lot of exciting possibilities but it is important to remain in focus and deliver a MVP useful for development and bringing community awareness now. + +**What DINFRA is not** + +DINFRA is not an Infrastructure Provider for the Dotsama ecosystem, but rather a parachain designed to arrange deployments between infrastructure consumers an infrastructure providers in a decentralized way. + +DINFRA may provide concrete infrastructure automation modules, but they will be open-source and infrastructure providers will be able to use them, modify them or utilize as reference implementation for their own. + +DINFRA is not meant to deliver a company or venture but rather a decentralized community that follows Polkadot's governance model and serve our ecosystem first. + +DINFRA will not become a way to just "open" infrastructure to the whole world. Blockchain features may be used for consumers to pick specific providers, providers to accept specific consumers even for consumers to manage their own infrastructure in a private way. Completely public infrastructure remains a valid use case but would benefit from on-chain features such as reputation, arbitrage, deposits, offenses, etc for it to be practically viable. + +### Ecosystem Fit + +As we can see with [Polkawatch](https://blog.polkawatch.app/introducing-polkawatch/), our infrastucture plays an important role in the level of effective decentralization of Substrate Validation process. + +Our treasuries invest significant funds on infrastructure, for which our ecosystem counts with fantastic providers. However, it is becoming clear that our ecosystem needs strategic actions at infrastructure level. Some projects have already been started by our treasuries, a good example being the [Infrastructure Builders Program](https://ibp.network/). + +DINFRA intents to provide an strategic approach to managing our ecosystem infrastructure using our biggest asset: Substrate itself. + +On the other hand our ecosystem is investing significant effort on Decentralized Finance. A successful DINFRA parachain, used to arrange delivery of our own infrastructure, would channel significant resources becoming effectively a Web3 commodity: a currency that everybody in our community needs and uses, backed by real, tangible, infrastructure services. This would provide health to our DEFI community as DEFI is often criticized for baking tokens with tokens non of which are backed by "real" assets. Commodities play an important role in traditional economies and the same could apply to our ecosystem. + +The target audience of DINFRA is therefore our Governance bodies, infrastructure providers, infrastructure consumers (Parachains, DAPPs, etc), and on the other hand substrate, UI and infrastructure engineers willing to contribute. + +Regarding similar projects, on top of strategic programs launched by our treasuries there is also [ThreeFold](https://www.threefold.io). An impressive decentralized infrastructure venture which utilities substrate technology while not being formally part of our ecosystem. We had the pleasure to meet their friendly team during the last Sub0 conference in Portugal and their experience was instrumental in realizing that DINFRA is far from a technological-only challenge and needed key design constraints for it to be acceptable to our ecosystem: inclusive to current infrastructure providers, non technically opinionated, community governed, strategically designed to serve our community first, etc. + +At a different level DINFRA is an attempt to orchestrate a set of independent providers that will appear to the consumer as a single entity. Effectively DINFRA could become a decentralized alternative to Public Clouds in the long term. Lessons learned from DINFRA could apply to other industries too. Any industry with an existing level of automation and many independent players could be orchestrated similarly + +## Team :busts_in_silhouette: + +### Team members + +- Rafael del Valle López +- René Moser + +### Contact + +- **Contact Name:** Rafael del Valle Lopez +- **Contact Email:** rvalle@valletech.eu +- **Website:** https://valletech.eu + +### Legal Structure + +- **Registered Address:** Blåmesv. 26, 186-47 Vallentuna, Sweden +- **Registered Legal Entity:** Valletech AB, Org. Num: 5590673694 + +### Team's experience + + +Rafael lives with his family in Sweden and has over 20 years experience creating Software Product, Services and Ventures. In the last years has started to contribute to Open Source projects in the Infrastructure field. A significant contribution to Open Nebula was the [Python Bindings](https://opennebula.io/pyone-python-bindings-for-open-nebula/), now part of the official distribution. More recently the [Privaz.io](https://privaz.io) project was created with the goal to facilitate the adoption of Private Clouds by small projects. Privazio is currently in use to deploy [Polkawatch](https://blog.polkawatch.app/introducing-polkawatch/), a Web3 Foundation project currently in production and backed both by Polkadot and Kusama treasuries. + +René Moser lives with his family in Switzerland and have been a software and systems engineer for over 20 years. René is co-author of [O'Reilly's "Ansible: Up & Running"](https://www.oreilly.com/library/view/ansible-up-and/9781098109141/) and longtime open source software developer and author of many Ansible Cloud Provider Automation integrations, such as Vultr, CloudStack, Exoscale, cloudscale.ch, Hetzner and became member of the Ansible Core Contributors Team. Furthermore, René is Apache Foundation CloudStack Project Management Committee member since 2015 and founded my own company [moser-systems.com](https://www.moser-systems.com/) with focus on "Cloud Automation, Scaling and Integration." currently delivering its flagship project [ngine.io](https://www.ngine.io/), a platform for cloud-agnostic services including autoscaling which has been released as open source software "[scalr](https://ngine-io.github.io/scalr/)". + + +René and Rafael met during an open source collaboration to deliver new Apache CloudStack automation features. + +### Team Code Repos + +- https://gitlab.com/polkawatch/polkawatch +- https://github.com/ngine-io/scalr +- https://github.com/ngine-io/ansible-collection-cloudstack +- https://gitlab.privaz.io/privazio + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/rvallel/ +- https://www.linkedin.com/in/resmo/ + + +## Development Status :open_book: + +The project has not started formal implementation yet. However we have performed a viability check of required deliverables. + +Most infrastructure deliverables belong to our domain of expertise per contributions made in the past to other open source projects, therefore is easy for us to ensure its viability. Intermediate interfaces don't have technical risk, they have important technical requirements when considering our project constraints but they are straight forward to deliver. + +Substrate deliverables are newer to us and imply a learning curve, however the amazing resources put together by the community at [substrate.io](https://substrate.io/): the tutorials, test frameworks, etc have allowed us to verify their viability. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3.5 months +- **Full-Time Equivalent (FTE):** 1 +- **Total Costs:** 47.000 USD + +### Milestone 1 — Infrastructure Provider SDK + +- **Estimated duration:** 1.5 month +- **FTE:** 1 +- **Costs:** 20.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 test functionality, implement a Chain Reactor, etc. | +| **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. | Chain Reactor API | We will create the API for Chain Reactors using API technologies (OpenAPI or similar) that facilitate language-agnostic implementations. | +| 2. | Chain Reactor RI | We will implement a Chain Reactor Reference Implementation based on Apache CloudStack that can run against the Apache CloudStack Simulator to facilitate further development. The RI will be written in Python as programming language and Ansible as automation stack| +| 3. | Chain Reactor RI Test Suite | We will release a comprehensive set of Chain Reactor RI Unit tests that should serve as guideline for TDD of other implementations, implmented with Python. | +| 4. | CD/CI Chain Reactor RI | Gitlab Pipelines will be created for Chain Reactor Reference Implementation that must serve as guideline to other implementations | +| 5. | SSH Key Derivation | A viability study and implementation of converter of Substrate Account Keys into SSH Keys based on ed25519. Implemented with NodeJS| +| 6. | Substrate Deployment Descriptors | Documented Examples of Deployment Descriptors for the Chain Reactor RI will be provided that would spawn Substrate Nodes under DINFRA.| + + +### Milestone 2 — Substrate Parachain + +- **Estimated duration:** 2 month +- **FTE:** 1 +- **Costs:** 27,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can run, test and contribute to the DINFRA parachain. | +| **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. | DINFRA Provider Pallet | It will allow for Accounts to register as providers, Providers to declare supported Deployment types and avilable capacity. Will Assign Deployments to Providers by simple means such as Round Robin, Random or Capacity Based. Implemented with Substrate/Rust.| +| 2. | DINFRA Subscription Pallet | It will represent a simple Subscription to pay for a deployment. Cost will be fixed per block. Deployments will be teared down when allocated Balance is consumed. Consumers will be able to cancel Subscriptions and any time, tearing down the deployment. Implemented with Substrate/Rust. | +| 3. | Chain Reactor Interface | A Substrate Interface will be created with Providers Chain Reactors so that Deployment Contracts can be Deployed and Teared Down. The interface will be based on standard Substrate interfaces OCW, RPC and/or sidecar service / REST | + + +## Future Plans + +We intend to continue to our second phase in the plan as described in our video presentation. We will use the deliverables from this release to: + +- Setup a DINFRA Test Network +- Generate awareness in our community +- Allow the community to test the system +- Pitch and demo: Treasuries, Infrastructure Providers, Developers +- Seek launching DINFRA with specific Dotsama use cases. + diff --git a/applications/DKSAP.md b/applications/DKSAP.md index 308422e8e06..676f7738745 100644 --- a/applications/DKSAP.md +++ b/applications/DKSAP.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# DKSAP -- **Project Name:** DKSAP - **Team Name:** DKSAP - **Payment Address:** 0xf4f463B9A0ADa68536423121e7Bf9E559ce54fAf(Ethereum ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 diff --git a/applications/DNFT.md b/applications/DNFT.md index 75bfab316e8..082d5606a55 100644 --- a/applications/DNFT.md +++ b/applications/DNFT.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# DNFT Protocol -* **Project:** DNFT Protocol * **Proposer:** [DNFT](https://github.com/DNFT-Team) * **Payment Address:** 1Atc7JjqeSw1PwxCsSr8KPHEKDoRfh5ERF * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/213#issuecomment-918946371) diff --git a/applications/Dante_Network.md b/applications/Dante_Network.md index e15ded2f4d4..069e835dd7f 100644 --- a/applications/Dante_Network.md +++ b/applications/Dante_Network.md @@ -1,8 +1,7 @@ -# W3F Grant Proposal +# Dante Network -- **Project Name:** Dante Network - **Team Name:** Dante Network -- **Payment Address:** 0xc92314a5f62FA54b272612804C9Ac70AC139F7B0 (Ethereum ERC20 USDT) +- **Payment Address:** 14yr1tovebKbRbxggduV1vbTPtRQtgzTXh9tdZ34w3pGbc4W (Polkadot (Statemint) USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Datagen_Project.md b/applications/Datagen_Project.md index 70f449a7e52..8d52bac98a1 100644 --- a/applications/Datagen_Project.md +++ b/applications/Datagen_Project.md @@ -1,9 +1,9 @@ -# W3F Grant Proposal +# Datagen Project -- **Project Name:** Datagen Project - **Team Name:** B-Datagray - **Payment Address:** 0x330330C5F676cec700CB30aF9E37D3012f525AeE - Ethereum Network - USDC - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/980#issuecomment-2061764807) ## Project Overview @@ -11,7 +11,7 @@ B-Datagray’s Datagen project concerns the development of a decentralized infrastructure for CPU/GPU cloud computing, in chain, through different blockchain components. -The Datagen infrastructure requires the creation of a Substrate-based blockchain with some key features: low latency time, high efficiency (compatibly with the decentralized nature of the network), high degree of decentralization (higher than a traditional PoS would allow) of the physical hardware providing the cloud computing (therefore requiring a customized consensus protocol) and in-chain (or near-in-chain) computation (no off-chain based solutions). +The Datagen infrastructure requires the creation of a Substrate-based blockchain with some key features: low latency time, high efficiency (compatibly with the decentralized nature of the network), high degree of decentralization (higher than a traditional PoS would allow) of the physical hardware providing the cloud computing (therefore requiring a customized consensus protocol) and in-chain (or near-in-chain) computation (no off-chain based solutions). The Datagen infrastructure primarily want to serve: privacy friendly search engines and browsers, decentralized Web3 games and other ones (for example decentralizing the hardware layer of PoS blockchains, typically hosted on AWS and similar, etc…). @@ -21,40 +21,40 @@ B-Datagray team is really interested in creating this solution because we think ### Project Details -Architecture: The infrastructure will rely on two main pillars: a fast and independent substrate based blockchain (Fast Blockchain FB) and a slower but more resilient Polkadot/ Kusama parachain (Heavy Blockchain HB). +Architecture: The infrastructure will rely on two main pillars: a fast and independent substrate based blockchain (Fast Blockchain FB) and a slower but more resilient Polkadot/ Kusama parachain (Heavy Blockchain HB). ![datagen_infrastructor_diagram](https://i.imgur.com/3VDy0Wm.png) -The actual cloud computing will happen in our FB Datagen (substrate based). The reason for which we are having the cloud computing in an independent blockchain is that we need our blocktime to be lower than Polkadot’s / Kusama’s blocktime (ideally < 1sec when the infrastructure is ready) to be able to provide cloud computing to most Web3 gaming applications and privacy-friendly search engines. +The actual cloud computing will happen in our FB Datagen (substrate based). The reason for which we are having the cloud computing in an independent blockchain is that we need our blocktime to be lower than Polkadot’s / Kusama’s blocktime (ideally < 1sec when the infrastructure is ready) to be able to provide cloud computing to most Web3 gaming applications and privacy-friendly search engines. While, what happens in this HB will be asynchronously and randomly verified in the Parachain. -We adopt the relativistic point of view of the data-flow from the user to explain the underlying process. +We adopt the relativistic point of view of the data-flow from the user to explain the underlying process. The user connects to the network (typically through the API of the application provider that is using the Datagen Infrastructure), than the user goes through the so called ECHO procedure: he/she sends a package of raw data to be processed by the network and the first validator that answers correctly to him/her is paired to the user on a one to one basis (this is the only PoW heavy-like process that is happening in the whole infrastructure and is done to pair any user with the most efficient validator to him/her, starting from the assumption that by geography and/or specific application in use and/or other factors not all the users and the same validators have the same latency time). -The user is now paired to a specific validator (for a given amount of time -in the magnitude of some weeks-; after that given amount of time the user will send periodically other ECHOs, to allow to reassess the efficiency of the validators in the network). +The user is now paired to a specific validator (for a given amount of time -in the magnitude of some weeks-; after that given amount of time the user will send periodically other ECHOs, to allow to reassess the efficiency of the validators in the network). The user (through the Application Provider’s API) sends raw data both to the paired validator in the FB Datagen and to the HB Polkadot’s Parachain. The validator in the FB must solve the raw computational request and turn it into a hash, within the blocktime, so, the hashed data must propagate in the whole FB, but there is no need for the raw data to be processed multiple times (like in a PoW) in the FB. So, what is verifiably shared by the validators of the FB is the series of hashes and not the reiteration of the same computational process. The FB, as a whole, is so behaving more alike a PoS blockchain than a PoW. -Since the blocktime of the Parachain is longer than the blocktime of the FB, both the raw data from the user and the hashed data from the validator are sent to the Parachain in an asynchronous way (typically it could be every 10 to 30 blocks of the FB). +Since the blocktime of the Parachain is longer than the blocktime of the FB, both the raw data from the user and the hashed data from the validator are sent to the Parachain in an asynchronous way (typically it could be every 10 to 30 blocks of the FB). The parachain is not re-computing all the raw and the hashed data, for the moment is just storing them in a verifiable way. ![datagen_deep_infrastructure_diagram](https://i.imgur.com/w0obsru.png) -**Example**: `raw data X` came from `user A`, resulting in `hash Y` from `validator A`. Randomly, the Parachain extracts some computational problems to be double-checked. For example, it can randomly extract `raw data X` for double-checking and entrust it to validator `B`, `C` and `D` (sending back the request to them in the FB). +**Example**: `raw data X` came from `user A`, resulting in `hash Y` from `validator A`. Randomly, the Parachain extracts some computational problems to be double-checked. For example, it can randomly extract `raw data X` for double-checking and entrust it to validator `B`, `C` and `D` (sending back the request to them in the FB). `B`, `C` and `D` compute `X` again. Presuming that the majority of `B`, `C` and `D` (so at least two of them) are honest, the majority of them should compute `X` and obtain the same hash (`hash Z`). They send the hash back to the Parachain, and than compare the hashes. If for at least two validators (between `B`, `C` and `D`) `hash Z` = `hash Y` (the same hash obtained by `validator A`), `validator A` is then presumed honest and can continue with its validating activity. If, instead, for at least 2 validators (between `B`, `C` and `D`) `hash Z` ≠ `hash Y`, `validator A` is presumed a liar. -Since to be a validator `A` needed both to provide GPU and/or CPU processing capacity and to buy and stake DataGen native tokens, is easy to impose an economical cost for the cheating `validator A` by making it loose staked coins as a consequence of its wrong computation. In this regard the Parachain acts as an authority for the random processes of the FB. +Since to be a validator `A` needed both to provide GPU and/or CPU processing capacity and to buy and stake DataGen native tokens, is easy to impose an economical cost for the cheating `validator A` by making it loose staked coins as a consequence of its wrong computation. In this regard the Parachain acts as an authority for the random processes of the FB. We prefer the use of a Parachain, instead of two FB or a HB of our own FB, because of the improved resiliency that the Polkadot ecosystem can provide. -We must underline that, even if the goal of this very complex design is to keep even the hardware layer as decentralized as possible (compared to a PoS network, where there is strong economic incentive for a validator to host the computing capacity on the top of centralized server farm like AWS) we can’t prevent the validators hosted on centralized providers to participate to the network. +We must underline that, even if the goal of this very complex design is to keep even the hardware layer as decentralized as possible (compared to a PoS network, where there is strong economic incentive for a validator to host the computing capacity on the top of centralized server farm like AWS) we can’t prevent the validators hosted on centralized providers to participate to the network. The trade-off for such a result would so impede efficiency and low latency that, instead of trying to attain it (for some ideological reason of decentralization per self) we think we should try keeping the hardware layer of the network _decentralized enough_. We think that this can be attained as a collateral result of the above explained ECHO procedure (whose primary goal is to increase the overall efficiency and decrease the overall latency time of the network, by pairing users and validators on the basis of response time). -This collateral positive externality happens since validators that are faster to respond to specific clusters of users are rewarded by the process with the right to provide the cloud computing power requested by those clusters, with meaningful consequences for the geographical distribution of the validators themselves: in some geographical contexts (US coasts or Western Europe), where the internet connection is fast and big server farms are close-by, this will keep the economic incentive for validators to be hosted in centralized server farms; on the opposite, in other contexts (like some parts of South-East Asia, Sub-Saharan Africa and LATAM), where broadband connection is slow or inexistent and server farms far away, there will be a strong economic incentive to set up independent hardware facilities to validate the activity of local or regional areas. +This collateral positive externality happens since validators that are faster to respond to specific clusters of users are rewarded by the process with the right to provide the cloud computing power requested by those clusters, with meaningful consequences for the geographical distribution of the validators themselves: in some geographical contexts (US coasts or Western Europe), where the internet connection is fast and big server farms are close-by, this will keep the economic incentive for validators to be hosted in centralized server farms; on the opposite, in other contexts (like some parts of South-East Asia, Sub-Saharan Africa and LATAM), where broadband connection is slow or inexistent and server farms far away, there will be a strong economic incentive to set up independent hardware facilities to validate the activity of local or regional areas. Those independent validators, while not optimally located to compete with AWS-hosted validators for users in the “north of the world”, can also become validators of last resort in the case in which the centralized server farms are not providing service anymore (it can be due to technical outage or political pressure for censorship or other factors). As said, the goal is not to expel AWS-hosted validators from the Datagen network, but to keep it decentralized enough while being at the same time low latency and computationally efficient. @@ -62,7 +62,8 @@ The only computational activity that is happening off-chain is (following the ex Ideally, we would like to explore some technic to keep light the blockchains long-term to keep it clean of old unnecessary raw data and just having hashes long term (that’s why we like so much Polkadot’s feature that allows blockchains to evolve without forking). -So Datagen is **NOT**: +So Datagen is **NOT**: + - providing cloud storage of processed data; - doing substantial stuff off-chain; - PoW; @@ -82,7 +83,7 @@ For the above explained reasons, we see Phala more like a complementary project In other ecosystems we can see different competitors, each one with a very different both technical and go to market approach (explaining them one to one will be too long to explain in this grant application), both off-chain and in-chain. -Off-chain SONM (independent copy-cat of the Ethereum blockchain), Aleph.im (Solana, cross-chain compatible). And (more or less) in-chain: Akash (Solana Nodes + Cosmos), Golem (Ethereum), Cudos (L1, independent, cross-chain compatible), StackOS (Binance Polygon, Avalanche) and others. +Off-chain SONM (independent copy-cat of the Ethereum blockchain), Aleph.im (Solana, cross-chain compatible). And (more or less) in-chain: Akash (Solana Nodes + Cosmos), Golem (Ethereum), Cudos (L1, independent, cross-chain compatible), StackOS (Binance Polygon, Avalanche) and others. The existence of many competitors (each different from the other) in many different stacks is for us a confirmation that we are working on something that matters and we think that for the Polkadot ecosystem is important to harbor different cloud computing projects, with different (in some points complementary and in other alternative) approaches, both to help boosting the wider Web3 environment to shift away from centralized Web2 providers like AWS, Google Cloud, Azure, IBM, Alibaba and to acquire and retain valuable projects while competing with other major stacks, because cloud computing matters a lot in the web economy and in the web physical infrastructure and for a top stack like Polkadot / Kusama should matter _where_ cloud computing, as a strategic asset, is happening. @@ -94,7 +95,8 @@ In particular is possible to observe that the Solana ecosystem is backing both o - Angela Griggio (CEO) - Luca Eugenio Barlassina (COO) -- Niccolò Baldini (Head of Substrate Division) +- Oliver Lim (Rust and Blockchain developer) +- Niccolò Baldini (Former_Head of Substrate Division) - Ren Okamoto (Head of Solidity Smart-Contracts Development) - Alawiye Olukayode (front end developer) - William Liu (part-time / blockchain developer) @@ -115,19 +117,19 @@ In particular is possible to observe that the Solana ecosystem is backing both o ### Team's experience -Both founders (Angela & Luca) have a legal background. They entered in the blockchain space in 2019 (shifting carrier) because they both strongly believe in the transformative power that the blockchain revolution can have on society. +Both founders (Angela & Luca) have a legal background. They entered in the blockchain space in 2019 (shifting carrier) because they both strongly believe in the transformative power that the blockchain revolution can have on society. -After ≈1 year of self-taught study of the blockchain technology and market, they incorporated B-Datagray in late 2020. At the beginning it was a very lonely but enriching journey, since they had 0 previous connection in the industry, 0 track record and 0 capital. Angela and Luca started being full-time on the project in January 2021. +After ≈1 year of self-taught study of the blockchain technology and market, they incorporated B-Datagray in late 2020. At the beginning it was a very lonely but enriching journey, since they had 0 previous connection in the industry, 0 track record and 0 capital. Angela and Luca started being full-time on the project in January 2021. -In Spring 2021 they started building the technical team (at the beginning all part time, due to the lack of capital) and not without encountering not particularly honest devs, while that made things more difficult short-term, long-term it allowed the funders to become more skilled in managing a team. Our currently beautiful team started to come togheter after summer 2021. +In Spring 2021 they started building the technical team (at the beginning all part time, due to the lack of capital) and not without encountering not particularly honest devs, while that made things more difficult short-term, long-term it allowed the funders to become more skilled in managing a team. Our currently beautiful team started to come togheter after summer 2021. -In that period, we also entered in the XEurope Accelerator. Ren (with 7 years of coding experience and 5 of Solidity coding) was the first to become mostly full-time, in October 2021, before we were able to pay him a salary. +In that period, we also entered in the XEurope Accelerator. Ren (with 7 years of coding experience and 5 of Solidity coding) was the first to become mostly full-time, in October 2021, before we were able to pay him a salary. In November B-Datagray received the first VC investment and to date we have 2 VC and 2 angel investments. We have developed all the tokenomic smart contracts, including a community governance smart contract to help smoothing the transition from the BSC to our Native + Polkadot blockchain and all of them have been audited by Certik. B-Datagray has also been recently finalist at the MIT Bitcoin Pitch Competition 2022. -We know that we still have much to grow and to learn, but all the journey until here and now taught to B-Datagray’s founder a great deal about bootstrapping and managing a company and about doing much with very little. +We know that we still have much to grow and to learn, but all the journey until here and now taught to B-Datagray’s founder a great deal about bootstrapping and managing a company and about doing much with very little. -The ability and willingness to learn and grow and change and to work hard and to believe, even in the most difficult moment, and to find the resources, in the inner-self and in the other people, even when is seemingly and rationally impossible, in our opinion is more important than any learned skill for team and project leaders, since is an attitude that you have inside you and that you express in every aspect of your personal and professional life and that will be determinant to solve any of the multiple problems that will inevitably and unexpectedly occur during the project’s lifetime. +The ability and willingness to learn and grow and change and to work hard and to believe, even in the most difficult moment, and to find the resources, in the inner-self and in the other people, even when is seemingly and rationally impossible, in our opinion is more important than any learned skill for team and project leaders, since is an attitude that you have inside you and that you express in every aspect of your personal and professional life and that will be determinant to solve any of the multiple problems that will inevitably and unexpectedly occur during the project’s lifetime. All our devs (and our designers) are professionals and also very committed to learning and improving constantly their skills. @@ -138,6 +140,7 @@ All our devs (and our designers) are professionals and also very committed to le - Alawiye ( https://github.com/oluseyi-frontend?tab=repositories ) - Luca (https://github.com/Lord-Nymphis ) - Niccolò ( https://github.com/viac92 ) +- Oliver (https://github.com/cuteolaf ) - Ren ( https://github.com/fantasy2345 ) - William ( https://github.com/Crypto-One-dev ) @@ -150,13 +153,14 @@ All our devs (and our designers) are professionals and also very committed to le - Giulia (https://www.linkedin.com/in/giulia-cortinovis-98702796/) - Luca (https://www.linkedin.com/in/luca-eugenio-barlassina-293077180/) - Niccolò (https://www.linkedin.com/in/niccol%C3%B3-baldini-0400baa9/) +- Oliver ( https://www.linkedin.com/in/oliver-lim-2215a8235/ ) - Ren (https://www.linkedin.com/in/ren-okamoto-140a97224/) - William (https://www.linkedin.com/in/william-liu-8a4672218/) ## Development Status -What we have already developed (using Solidity) is all the tokenomic smart contracts regulating our DataGen token (#DG), including one to smooth the transition from the BSC network to the Polkadot / Native Datagen Infrastructure, with a rigorously decentralized community voting procedure (https://github.com/Datagen-Project/DataGen-Smart-Contracts/blob/main/contracts/MiningReservation.sol). +What we have already developed (using Solidity) is all the tokenomic smart contracts regulating our DataGen token (#DG), including one to smooth the transition from the BSC network to the Polkadot / Native Datagen Infrastructure, with a rigorously decentralized community voting procedure (https://github.com/Datagen-Project/DataGen-Smart-Contracts/blob/main/contracts/MiningReservation.sol). In total our team has already developed around ≈2K lines of code of smart contracts just for the Datagen project, excluding of course the default configurations (like lock.json , etc…), we are speaking of functional code. In addition to that, we have in private repo the functional code for the website and the sale interface. @@ -171,7 +175,7 @@ The goal is to achive a fully functional mechanism for the random selection of t ### Overview -- **Total Estimated Duration:** 5 months (starting date - August 2022) +- **Total Estimated Duration:** 5 months (starting date - August 2022) _ Update: Because of changes in the development team M2 delivery date will be ≈15th of March 2023, with relative shift of the whole timeline. - **Full-Time Equivalent (FTE):** 2 - **Total Costs:** 44,000 USD @@ -189,11 +193,11 @@ The goal is to achive a fully functional mechanism for the random selection of t | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | 0e. | Article | We will publish an **article** on Medium that explains how we are going to develop the pallet. | | 1. | Substrate pallet | We will create a `pallet_random_node_selector` that implement the randomized selection of the nodes for the fast blockchain using the Substrate `Randomness` trait. This pallet run on the Heavy Blockchain. | -|1a.| Functions |
  • `reliable_node` update the list of the reliable nodes on the Heavy Blockchain.
  • `random_checker_node_selector` select 3 reliable random nodes in the fast blockchain to check the computational work.
  • `random_node_to_check` select a single random node to be check by the 3 checker nodes.
+|1a.| Functions |
  • `reliable_node` update the list of the reliable nodes on the Heavy Blockchain.
  • `random_checker_node_selector` select 3 reliable random nodes in the fast blockchain to check the computational work.
  • `random_node_to_check` select a single random node to be check by the 3 checker nodes.
|2.| Substrate pallet | We will create a `pallet_computational_work` that runs computational work on the fast nodes and pair them with their works. |2a.| Functions |
  • `math_work_testing` this function will provide math problems to solve by Fast Blockahin nodes, just for testing.
  • `hash_work` function will hash the raw math problem and the elaborated result from the node and pair, comunicate to the Heavy Blockchain.
|3.| Substrate pallet| We will crate a `pallet_check_node_computational_work` that manage the control process on the Fast Blockchain. -|3a.| Functions |
  • `check_computational_work` take info from the Heavy Blockchain (from the `pallet_random_node_selector`) and check the computational work of the target node. At this moment the nodes will make a simple math calculations just to check the mechanism.
  • `check_result` elaborate the result of the check process. If checked node has the same result of the majority of the checker nodes nothing happen. If the majority of the nodes have a different result from checked node this one will lose all his staked tokens (at this moment we only simulate the token lost) and checked node will be excluded from the Fast Blockchain.
  • `reliable_node` update the list of the reliable nodes on the Fast Blockchain.
+|3a.| Functions |
  • `check_computational_work` take info from the Heavy Blockchain (from the `pallet_random_node_selector`) and check the computational work of the target node. At this moment the nodes will make a simple math calculations just to check the mechanism.
  • `check_result` elaborate the result of the check process. If checked node has the same result of the majority of the checker nodes nothing happen. If the majority of the nodes have a different result from checked node this one will lose all his staked tokens (at this moment we only simulate the token lost) and checked node will be excluded from the Fast Blockchain.
  • `reliable_node` update the list of the reliable nodes on the Fast Blockchain.
### Milestone 2 — Connecting the two blockchains @@ -231,10 +235,10 @@ The goal is to achive a fully functional mechanism for the random selection of t | 1. | Web Dapp | We will create a web dapp to verify the functionality of the infrastructure, the GUI will display interactions between the two blockchains. | | 1a.| Dapp Mock-up| Download the mock-up of the dapp at [this link](https://drive.google.com/drive/folders/1SJRPbczZhRaXVLHnLvmp_XIeBtBBv0g-). | | 1b. | Home page | ![home page](https://i.imgur.com/MhQVfEj.png)
  1. Filter to switch between the two blockcahins for searching purpose
  2. Searching field (could search for blocks or nodes by typing id)
  3. The id of the last node checked with `check_computational_work` pallet
  4. The total number of nodes checked with `check_computational_work` pallet
  5. Total checks with `check_computational_work`
  6. Avarage number of checks on a single fast node with `check_computational_work` pallet
  7. Id of a fast blockchain node
  8. Number of checks on a node with `check_computational_work` pallet
  9. The fast nodes that verify the computational work with `check_computational_work` pallet
  10. Check result from `check_computational_work` pallet
  11. Total blocks finalized by the blockcahin
  12. Total nodes of the blockchain
  13. Block height
  14. Block age
  15. Validator id of the block
| -| 1c. | Fast Blockchain - Block Page| ![FB Block](https://i.imgur.com/ZDMuX7I.png)
  1. Blockchain identifier
  2. Block identifier (height)
  3. Block height, arrows change the block by 1 (left -1, right +1)
  4. The age of the block and its creation time
  5. Validator identifier, optionally a name and time required to validate the block
  6. Total number of fast nodes at this block height
  7. Number of nodes checked with `check_computational_work` pallet in this block
      8. | +| 1c. | Fast Blockchain - Block Page| ![FB Block](https://i.imgur.com/ZDMuX7I.png)
      1. Blockchain identifier
      2. Block identifier (height)
      3. Block height, arrows change the block by 1 (left -1, right +1)
      4. The age of the block and its creation time
      5. Validator identifier, optionally a name and time required to validate the block
      6. Total number of fast nodes at this block height
      7. Number of nodes checked with `check_computational_work` pallet in this block
      | | 1d. | Heavy Blockchain - Block Page | ![HB Block](https://i.imgur.com/iJCc6nh.png) For functionalities see 1c. list. | -| 1e. | Fast Blockchain - Node Page | ![FB Node](https://i.imgur.com/wOBlIdp.png)
      1. Node identifier
      2. Node identifier arrows change the node by 1 (left -1, right +1)
      3. Blockchain identifier
      4. Last time node checked with `check_computational_work` pallet.
      5. Total number of checks with `check_computational_work` pallet on this node
      6. How many pass results on this block
          7. | -| 1f. | Heavy Blockchain - Node Page | ![HB Node](https://i.imgur.com/IYEyVzA.png) For functionalities see 1e. list.| +| 1e. | Fast Blockchain - Node Page | ![FB Node](https://i.imgur.com/wOBlIdp.png)
          1. Node identifier
          2. Node identifier arrows change the node by 1 (left -1, right +1)
          3. Blockchain identifier
          4. Last time node checked with `check_computational_work` pallet.
          5. Total number of checks with `check_computational_work` pallet on this node
          6. How many pass results on this block
          | +| 1f. | Heavy Blockchain - Node Page | ![HB Node](https://i.imgur.com/IYEyVzA.png) For functionalities see 1e. list.| ## Future Plans diff --git a/applications/DecentralizedThresholdSigningService.md b/applications/DecentralizedThresholdSigningService.md new file mode 100644 index 00000000000..aa1ff146efc --- /dev/null +++ b/applications/DecentralizedThresholdSigningService.md @@ -0,0 +1,133 @@ +# Decentralized Threshold Signature Service Implementation + +- **Team Name:** Rui Morais +- **Payment Address:** + - FIAT (Sent by email to grants@web3.foundation on 09/08/2024, 16:07 UTC+1) + - Polkadot: 14bBGQFAgKqdbGVDSWkm6dA8ZQzt9GxGSTALrD8SeafWW9gL +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Description :page_facing_up: + +### General Overview + +This project is a continuation of [this one](https://github.com/w3f/Grants-Program/pull/2250) and aims to build a decentralized threshold signing service leveraging the Olaf protocol. The service will operate off-chain, providing a secure and cost-effective alternative to on-chain threshold signature mechanisms within the Substrate/Kusama/Polkadot ecosystem. + +### Technical Details + +Each participant in the threshold signing group will run a browser-based application that performs decentralized key generation and signing operations through the Olaf threshold signature protocol, compiled to WebAssembly (WASM). The networking layer is built using JavaScript and `libp2p` for peer discovery and communication. + +#### 🌐 Networking Layer (JavaScript) + +##### Transport +- Peers connect to a relay server using WebSockets. + +##### Discovery +- When a peer connects, it sends its Substrate/Polkadot/Kusama address to the relay server. +- The relay server assigns the peer a random `libp2p` Peer ID and stores the mapping: +Address → Peer ID + +- Peers can query the relay server with a known blockchain address to obtain the corresponding Peer ID. + +##### Direct Peer Communication +- Once a Peer ID is obtained, the peer establishes a WebRTC connection using `libp2p`. +- All protocol messages are exchanged via this secure, direct P2P channel. + +#### 🔐 Cryptographic Protocol (Rust → WASM) + +The cryptographic logic is written in Rust and compiled to WebAssembly (WASM) for browser use. + +##### Core Functionality +- Distributed Key Generation (DKG) to derive a shared threshold public key. +- Threshold Signing for signing Substrate/Kusama/Polkadot extrinsics. + +##### State Management +- Key shares and protocol state are stored in browser-local storage (e.g., `IndexedDB`). + +### Ecosystem Fit + +This project is useful for any Substrate/Kusama/Polkadot based project that wants to use a secure off-chain decentralized threshold signature service that is cheaper than using the theshold signing funcionality of the network directly. + +### Related Projects + +The most similar project we found is [this](https://github.com/nulltea/tss-libp2p), but it is out of date and unmantained. + +### Team members + +- Rui Morais + +### Contact + +- **Contact Name:** Rui Morais +- **Contact Email:** ruipedromorais11@gmail.com +- **Github:** https://github.com/fiono11 +- **Linkedin:** https://www.linkedin.com/rui-morais + +### Team's experience + +- Obtained a PhD in Computer Science with the thesis *"Contributions to Permissionless Decentralized Networks for Digital Currencies Based on Delegated Proof of Stake"* (awaiting for the defense). +- Published the following papers: + - [Echidna: A New Consensus Algorithm for Efficient State Machine Replication](https://ieeexplore.ieee.org/document/10338927) (IEEE BCCA 2023) + - [Nero: A Deterministic Leaderless Consensus Algorithm for DAG-Based Cryptocurrencies](https://www.mdpi.com/1999-4893/16/1/38) (Algorithms 2022) + - [A tool for implementing privacy in Nano](https://ieeexplore.ieee.org/document/9126023) (IEEE DAPPS 2020) + - [Adamastor: a New Low Latency and Scalable Decentralized Anonymous Payment System](https://arxiv.org/abs/2011.14159) (Arxiv) +- Has graduated the PBA Hong Kong cohort. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 30,000 USD +- **DOT %:** 50% + +### Milestone 1 - Peer Discovery via Blockchain Address + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide **inline documentation** of the code. | +| **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.a** | Peer Discovery via Blockchain Address | Two browsers connect to a relay server, register with a Substrate/Kusama/Polkadot address, discover each other, and exchange messages directly over WebRTC using `libp2p`. | + +### Milestone 2 - Distributed Key Generation + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide **inline documentation** of the code. | +| **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.a** | Distributed Key Generation | Two browsers exchange messages and successfully produce a shared threshold public key using the Olaf DKG protocol compiled to WASM. | + +### Milestone 3 - Threshold Signature + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **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** that explains how the service can be used. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| **0e.** | Article | We will publish an **article**/workshop that explains how the service works under the hood and how it can be used from a user perspective. | +| **1.a** | Threshold Signature | Two browsers exchange messages and produce a valid threshold signature over a given Substrate/Kusama/Polkadot extrinsic using the Olaf protocol compiled to WASM. | + +## Future Plans + +Build a production-ready, secure Progressive Web App (PWA) that includes: +- Robust asynchronous peer-to-peer communication. +- Support for configurable t-out-of-n threshold schemes. +- Add proof of ownership to prevent address spoofing. +- Implement a network of relay servers to achieve full decentralization. diff --git a/applications/DeepAccountAnalytics-PolkadotDataAlliance.md b/applications/DeepAccountAnalytics-PolkadotDataAlliance.md new file mode 100644 index 00000000000..d7704358d97 --- /dev/null +++ b/applications/DeepAccountAnalytics-PolkadotDataAlliance.md @@ -0,0 +1,307 @@ +# Web3 Foundation Deep Account Analytics in Three Tiers for the Polkadot Data Alliance + +- **Team Name:** Colorful Notion, Inc. +- **Payment Address** `0xEaf3223589Ed19bcd171875AC1D0F99D31A5969c` +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Abstract :page_facing_up: + +This proposal addresses outstanding [deep account analytics problems for the Web3 Foundation](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md). +We propse 3-tier solution: + + - Tier 1. _raw indexing_: Google BigQuery Public Datasets + - Tier 2. _deep indexing_: shared datasets delivered with Google Analytics Hub + - Tier 3. _dashboards_: the above indexed data in Apache Superset + +This proposal seeks to develop the above solution with the support of a Web3 Foundation grant, but critically addresses +future maintainance a [Polkadot Data Alliance Bounty](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#) +that can support work on all 3 tiers with _child bounties_ for Polkadot Data Alliance contributors. + +## Project Overview :page_facing_up: + +This proposal is in response to the RFP [Data Analysis Tools for Substrate-based Blockchains](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/data_analysis_tools.md) +which seeks to answer deep account analytics questions of: + +**Account References**: +* Which transactions/accounts were responsible for the reserved balance in an account? +* What modules currently depend on consumers, providers, and sufficients reference counters for a certain account, and which transactions introduced/removed those references? +* What are the pallets responsible for reserves/holds and locks/freezes on an account? + +**Democracy**: +* Which accounts have delegated OpenGov votes to an account or to which accounts the account in question has delegated their votes to for each track? + +**Staking/Nomination Pools**: +* Who are all the nominators that nominated Validator X? (an inverse mapping basically of staking.nominators from validator -> nominators) +* Who are the top 10 nominators with the highest APR, and which validators do they have in common? + +We call these _deep analytics_ questions because to answer them requires significant "deep indexing" beyond "raw indexing", which cannot be done without intricate knowledge of Substrate. Currently, these questions are difficult to answer without going through many pages in a block explorer like Polkaholic.io, and nearly impossible without doing some amount of data engineering. The answers to the above questions _could_ be treated as new features to be developed in the context of block explorer like Polkaholic, or within special purpose UIs like polkassembly or staking.polkadot.network. + +We propose a different style of solution that we believe properly factorizes the following _three_ tiers: +* Tier 1. raw indexing - raw indexing of decoded blocks (blocks, extrinsics/calls, events, traces) +* Tier 2. deep indexing - post-processing of raw indexed data +* Tier 3. dashboards - situating the above with BI tools -- speci that does not require deep knowledge of the structure of the indexed data + +Typically, a block explorer or special purpose UI concerning chain +data blends all of these three tiers together -- and the maintainer of +the block explorer enjoys a community following (etherscan.io ). But +often when new deep analytics questions arise are not directly +available in an explorer, users with deep account analytics questions +are left struggling and need custom answers only provided by data +engineers and analytics engines -- covered by dashboard systems like +Dune Analytics. In Dune Analytics, Tier 2 is covered by Dune Wizards +and Tier 3 is covered with a customized front-end. + +The solution we develop here is _not_ to make a long list of feature +requests for either block explorers or special purpose UIs to answer +with new functionality. + +Instead, our solution to this problem is to separate the THREE TIERS within a _genuinely collaborative_ Polkadot Data Alliance: + +* Tier 1: raw indexing results in all blocks, extrinsics, events, traces delivered in Google Bigquery Public Datasets. In May 2023, Colorful Notion, under the curation of Parity Data, onboarded a complete index of 70+ chains of Polkadot+Kusama into Google Public Datasets. This is in the "crypto_polkadot" and "crypto_kusama" dataset, which anyone can access with this Analytics Hub link [here](https://console.cloud.google.com/bigquery/analytics-hub/exchanges/projects/974572213039/locations/us/dataExchanges/substrate_18804f88005/listings/polkadot_188057df28c?project=github-integration-295917) and [here](https://console.cloud.google.com/bigquery/analytics-hub/exchanges/projects/974572213039/locations/us/dataExchanges/substrate_18804f88005/listings/kusama_1880581b627?project=github-integration-295917). + +* Tier 2: deep indexing can then be done by doing some amount of data engineering with the above raw deata, resulting in tables, views or materialized views that can also be shared with new datasets, which can also be shared with Analytics Hub. + +* Tier 3: front-end engineering: given the above dataset, an open source BI tool (Apache Superset) can access _multiple_ datasets contributed by _multiple_ Polkadot Data Alliance members. Recently, Parity Data shared this dataset of _their_ index of Polkadot, which enables a simple comparison between Parity Data's index and Colorful Notions' index. + +We consider our approach a _genuinely collaborative_ approach, because anyone can contribute at any of the 3 tiers -- providing raw indexes, deep indexes, or dashboards. All dataset deliverables are public and the data processing itself is also reproducible in a "ETL" flow. This should be contrast to a _non-collaborative_ approach where dataset is kept locked away unshared with the community, closed source and thus irreproducible. + +However, because all three tiers involve a certain amount of storage, compute and data engineering/data analyst man power, it is critical to not _just_ build the above three tiered solution, +but recognize that it needs **maintainence**. The Web3 Foundation supports maintainence, but does not support the considerable cloud computing costs that Tier 1 and 2 require, nor the sort of solution that Tier 3 requires. We thus propose that the above three tier architecture be situated _in conjunction with_ a [Polkadot Data Alliance bounty](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#), not just for ourselves at Colorful Notion, but for everyone equally commited to genuine collaboration a Polkadot Data Alliance. + +It is believed that this collaborative framework can address many different problems other than deep analytics, and result in a more efficient allocation of Treasury funds and parachain resources: including an industry-wide multichain block explorer, ecosystem-wide XCM indexing, tracing tools, to name a few that our team has explored with some depth of seriousness. + +Much Tier 1 foundation has already been laid through our work and other indexers (Subquery, Subsquid, Subscan, web3go) in the ecosystem, who we hope will be able to contribute at Tier 1 [ideally within BigQuery so as to be directly usable as another source for Tier 2 and Tier 3]. + +But Tier 1 is not enough -- it is necessary to address Tier 2 and Tier 3 as well, and the Web3 Foundation RFP questions clearly illustrate the inadequacy of stopping with raw indexes and the need for deep indexing. We believe a strong collaborative mindset is required to fully address these questions and numerous others the Substrate ecosystem asks comprehensively. + +The goal of this proposal is to: +* address the Web3 Foundation's specific deep account analytics questions fully, specifically with three-tiered deliverables at Tier 1+2+3, using widely used tools of Google BigQuery and Apache Superset +* demonstrate a viable financial path for our own maintainence for the above solution within the Web3 Foundation grant structure and the structure of the Polkadot Treasury using the Polkadot Data Bounty system +* form an alternate kind of deliverable for Web3 Foundation other than code that everyone can use: _datasets_ and _dashboards_ that everyone can use + +### Project Details + +The "Account References" questions of +* Which transactions/accounts were responsible for the reserved balance in an account? +* What modules currently depend on consumers, providers, and sufficients reference counters for a certain account, and which transactions introduced/removed those references? +* What are the pallets responsible for reserves/holds and locks/freezes on an account? + +are largely answerable through traces. At the heart of every +blockchain is a state transition function, where the state transitions +for any block are commonly called "traces" in blockchain engineering. +Substrate makes every trace visible through a +[state_traceBlock](https://polkadot.js.org/docs/substrate/rpc/#traceblockblock-hash-targets-optiontext-storagekeys-optiontext-methods-optiontext-traceblockresponse) +RPC function, which outputs every storage key-value map change in a +re-execution of a single block. This RPC call is considered "unsafe" +as it requires compute time to regenerate. + +Polkaholic.io's indexer, when traces are available from an internal archive node, fetches traces and exposes them in the block explorer. +For example, here is the trace for [Polkadot Block 15723663](https://polkaholic.io/trace/polkadot/15723663/) + + + +The raw keys (e.g. `0x26aa394eea5630e0...f1dbd372bbe532b1f8702b2a7e`) and values (e.g. `0x01ab50050...000000000000`) are decoded using the chains type spec into + +``` +Key: [ "12xtAYsRUrmbniiWQqJtECiBQrMn8AypQcXhnQAc6RB6XkLW" ] +Value: { + "nonce": 348331, + "consumers": 2, + "providers": 1, + "sufficients": 0, + "data": ⊖{ + "free": "0x000000000000000005785a9c9f9ad21b", + "reserved": 0, + "miscFrozen": "0x00000000000000000058d15e17628000", + "feeFrozen": "0x00000000000000000058d15e17628000" + } +} +``` + +and loaded into BigQuery as part of a publicly available [substrate-etl](https://console.cloud.google.com/bigquery/analytics-hub/exchanges/projects/974572213039/locations/us/dataExchanges/substrate_18804f88005), recently added to Google BigQuery's Public Datasets in May 2023. + + + +In Milestone 1, we will provide a 3 tier solution to deep account analytics on Account References. Here is how the 3 tiers: + +* Tier 1 requires *raw indexing* of traces. Traces are critical to Colorful Notion's [XCM Indexing](https://polkaholic.io/xcmtransfers?xcmType=xcmtransfer) and are important for parachain engineers to understand how the execution of a block, and are critical to the model producers, consumers and sufficients. As raw traces form a very large dataset, to keep storage costs low, the indexer filters out pallets section/method that and exposes them in `crypto_polkadot.traces0` ([see schema](https://github.com/colorfulnotion/polkaholic/blob/main/substrate/schema/substrateetl/traces.json)). In particular, given how central accounts and native and non-native tokens are to blockchain usage, the indexer further decodes accounts and asset state into many additional columns like free, reserved and frozen. + +* Tier 2 requires *deep indexing* of the above trace data, to analyze how certain attributes changed in [System:Account](https://docs.google.com/spreadsheets/d/1jywN--pONmJqmbuASWDLNdBvsB86OuizJnQ72ijAXSU/edit#gid=704412439) holding account reference counters, account balance reserved provenance (see: https://docs.substrate.io/reference/account-data-structures/). We have some preliminary work on this (see [this sheet](https://docs.google.com/spreadsheets/d/1gZZOvH4BYk2QYlhzz9AvRxiR6mcYtgRz9VZluz1lwuU/edit#gid=1313769699)) and proved that, yes, it is indeed possible to uniquely identify the extrinsic id (but not call id) for every trace, and that the changes can be identified to build a new dataset every day. + +* Tier 3 requires situating the above dataset into an Account Analysis Dashboard of [Apache Superset](https://analytics.polkaholic.io/dashboard/list/). Here we have a WASM Contract Explorer prototype: + + + +We envision Milestone 1 focussed on Account References and then extended in Milestone 2 to Democracy+Staking deep analysis. This will result in an Account Analysis Dashboard, with 3 or more account tabs exploring: + +* "Account References" concerning deep indexing developed in Milestone 1 + +* "Democracy" concerning deep indexing about [Democracy:VotingOf](https://docs.google.com/spreadsheets/d/1hdvW5Kw3gwBnXqFskALX1_szdTf4pYL-SlbOqJ8tlO0/edit#gid=1803912396) developed in Milestone 2 + +``` +{"direct":{"delegations":{"capital":0,"votes":0},"prior":[0,0],"votes":[[113,{"standard":{"vote":"0x81","balance":10000000000}}],[119,{"standard":{"vote":"0x82","balance":50000000000}}]]}} +``` + +OR + +``` +{"delegating":{"balance":15000000000,"conviction":"Locked4x","delegations":{"capital":0,"votes":0},"prior":[0,0],"target":"15ZvLonEseaWZNy8LDkXXj3Y8bmAjxCjwvpy4pXWSL4nGSBs"}} +``` + +* "Staking" concerning deep indexing about Staking and Nomination Pools, with the added complexity of stashing controller/accounts, developed in Milestone 2. + +It is straightforward to link these dashboards directly to polkaholic.io based the key (accountID/extrinsicID/...) and add filtering on any column present in the table with Apache Superset. + +Any UI can then link to this dashboard with the account ID, and the dashboard can link back to a block explorer. + +Once the dataset is made available, end users can build charts and dashboards with the same ease as they do in Excel or Google Sheets. + +The community dashboard can be used in the same way as Dune Analytics dashboards serves the EVM community. + + +### Ecosystem Fit + +While this proposal does not explicitly require collaboration on any of the 3 tiers, our intention is to: +1. set up a foundation where the Web3 Foundation could ask other teams to contribute datasets (Tier 2) and build dashboards (Tier 3) in the same way. +2. set up a repeatable model between Web3 Foundation and a Polkadot Data Alliance support data-oriented research (W3F) and ongoing maintenance ([Polkadot Data Bounty](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#)) with child bounties + +## Team :busts_in_silhouette: + +### Team members / Contact + +- **Contact Name:** Sourabh Niyogi / Michael Chung +- **Contact Email:** sourabh@colorfulnotion.com / michael@colorfulnotion.com +- **Website:** https://colorfulnotion.com + +### Legal Structure + +- **Registered Address:** 55 E 3rd Ave, San Mateo, CA 94401, USA +- **Registered Legal Entity:** Colorful Notion, Inc. + +### Team's experience + +* Key engineers Sourabh Niyogi and Michael Chung have developed Polkaholic.io since Fall 2021 and substrate-etl since December 2022. + +* Prior to building Polkaholic.io, Sourabh and Michael worked in decentralized social networking protocol development + privacy-preserving contact tracing (Wolk), +mobile advertising real-time bidding algorithm design and analytics (CrossChannel/MdotM). + +* Sourabh spent time doing computational cognitive science and machine vision research at MIT, including +in [Bayesian learning of verb meaning and causal laws](https://scholar.google.com/citations?user=HHmGYdEAAAAJ&hl=en]. + +* Michael hails from UC Berkeley with a degree in statistics and economics and leads deep indexing at Colorful Notion. + +### Team Code Repos + +- [substrate-etl](https://github.com/colorfulnotion/substrate-etl) +- [Polkaholic.io](https://github.com/colorfulnotion/polkaholic) +- [XCM Global Asset Registry](https://github.com/colorfulnotion/xcm-global-registry) +- [Sourabh Niyogi](https://github.com/sourabhniyogi) | [Michael Chung](https://github.com/mkchungs) + +## Development Status :open_book: + +* Summer 2022: Released Polkaholic.io, a fully working Substrate-first multichain block explorer. +* Fall 2022: Increased XCM Transfers Coverage, Improved UI + API based on feedback from users. Added EVM/WASM support. +* Winter/Spring 2023: Developed substrate-etl and XCM Global Asset Registry. +* May 2023: Google included Polkadot + Kusama in [Google Public Datasets](https://cloud.google.com/bigquery/public-data). + +## Development Roadmap :nut_and_bolt: + +This proposal aims to deliver on the three-tier architecture outlined in two milestones: + +* Milestone 1 will develop `System:Account` deep analytics. +* Milestone 2 will develop `Democracy`, `Staking` and `NominationPools` deep analytics. + +For each Milestone, there are 3 kinds of deliverables corresponding to the 3 tiers: +- 1. Raw indexes, in the form of BigQuery datasets which are delivered +- 2. Deep indexes, in the form of BigQuery dataset +- 3. Dashboard publication, in the form of Apache Superset Dashboard + +All raw and deep indexing code will be made open source within the polkaholic and substrate-etl repo. + +### Overview + +- **Total Estimated Duration:** 4 months +- **Full-Time Equivalent (FTE):** 300 FTE hours [100 USD/hr] +- **Total Costs:** 30,000 USD + +### Milestone 1 — Three Tier Deep Account Analytics on Account References + +- **Estimated duration:** 8 weeks (ending 8/31/23) +- **FTE:** 150 FTE hours [100 USD/hr] +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | GNUv3 - polkaholic + substrate-etl repo | +| 0b. | Documentation | Provide README on construction of 1+2+3 | +| 0c. | Manual Testing Guide | Manual testing guide with steps for using the application, with examples including expected inputs and outputs | +| 1. | Raw Indexing | substrate-etl:crypto_polkadot.traces0 for 7/1/23 - 8/31/23 | +| 2. | Deep Indexing | substrate-etl:substrate.accountreference0 and supporting datasets | +| 3. | Dashboard Publication | Superset dashboard tab: "Account Reference" | + +We will take this opportunity to deliver raw indexes on traces, deep indexes on account references and a dashboard on Account References hosted at https://analytics.polkaholic.io. + +Indexing + Dashboard Publication must be able to support deep analysis of **Account References**: +* Which transactions/accounts were responsible for the reserved balance in an account? +* What modules currently depend on consumers, providers, and sufficients reference counters for a certain account, and which transactions introduced/removed those references? +* What are the pallets responsible for reserves/holds and locks/freezes on an account? + + +### Milestone 2 — Three Tier Deep Account Analysis of Democracy+Staking+Nomination Pools + +- **Estimated duration:** 8 weeks (ending 10/31/23) +- **FTE:** 150 FTE hours [100 USD/hr] +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | GNUv3 - polkaholic + substrate-etl repo | +| 0b. | Documentation | Document substrate-etl README on 1+2+3 | +| 0c. | Manual Testing Guide | Manual testing guide with steps for using the application, with examples including expected inputs and outputs | +| 1. | Raw Indexing | BigQuery Index substrate-etl.crypto_polkadot.traces0 9/1/2023-10/31/23 -- stashing accounts | +| 2. | Deep Indexing | BigQuery substrate-etl:substrate.democracy_* substrate-etl:substrate.staking_* substrate-etl:substrate.nomination_pools_* | +| 3. | Dashboard Publication | Superset dashboard tabs: "Democracy", "Staking", "Nomination Pools" | + +We will take this opportunity to address the complexity of stashing accounts by: +* Deep Indexing. Using the above tables in the views referencing `storage_staking_*, storage_nominationpools_*` tables +* Dashboard Publication. Using the above, we can develop dashboards for Democracy+Staking+Nomination Pools + +Indexing + Dashboard Publication must be able to support deep analysis of Democracy and Staking/Nomination Pools pallets: +* Democracy: Which accounts have delegated OpenGov votes to an account or to which accounts the account in question has delegated their votes to for each track? +* Staking/Nomination Pools: Who are all the nominators that nominated Validator X? (an inverse mapping basically of staking.nominators from validator -> nominators) Who are the top 10 nominators with the highest APR, and which validators do they have in common? + +## Future Plans + +Broadly, this proposal sets up a path for the Web3 Foundation to have Polkadot Data Alliance contributors deliver results for the Web3 Foundation itself and the community in the following ways: + +1. within the three-tier architecture, Polkadot Data Alliance contibutors can collaborate with Web3 Foundation and others in the Substrate community using raw indexes, published deep indexes, or building and extending dashboards. Our technical choice for collaboration is BigQuery and Apache Superset but other choices may be equally viable or appropriate, by other teams. + +2. with the [Polkadot Data Alliance Bounty](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#) and the [Web3 Foundation Maintance Grants](https://github.com/w3f/Grants-Program#hammer_and_wrench-maintenance-grants), there is a clear path to support both software maintainence _and_ hosting / data indexing infrastructure + +In followup work, we would expect to address the 3 tiers: +* raw indexing: cover traces on a regular basis defined in child bounties +* deep indexing: support the dataset deliverables on a regular basis +* dashboards: maintain published dashboards developed, and host the Apache Superset + +We would welcome the challenge of doing followon high impact work, but hope that others in the Polkadot Data Alliance can follow this model as well. + +We propose a child bounty to host Apache Superset instance at https://analytics.polkadot.network or transfer this responsibility to a parent bounty curator. + +## Additional Information :heavy_plus_sign: + +We request suitable Web3 Foundation members be identified as parent +and child bounty curator candidates, and that the charter for the +Polkadot Data Alliance be developed in a collaboration with Parity. +The Polkadot Data Alliance charter is [here](https://docs.google.com/document/d/1fA5ARHy-frzgZC66rniKZ5o7CSbDvCTkS--kWaMzuMs/edit#). + +We do not believe our participation (or anyone else's participation) +in a Polkadot Data Alliance in providing deliverables at any of the +three tiers eliminates the possibility of doing further data +processing for other sources of additional revenue. Our goal is to be +self-sufficient and not dependent on W3F Grants or Treasury funding, +but we hope our value and commitment to sharing and collaboration is +recognized by the community so we can be productive high impact +contributors. + + + diff --git a/applications/Deitos_Network.md b/applications/Deitos_Network.md new file mode 100644 index 00000000000..9479ad23b38 --- /dev/null +++ b/applications/Deitos_Network.md @@ -0,0 +1,306 @@ +# Deitos Network + +- **Team Name:** Deitos Network +- **Payment Method:** USDT (ID 1984) / Polkadot Assethub +- **Payment Address:** 12DrpztfgAKVubPVv1KcichaW5L4YJutmLGz665xwmbaicrM +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Deitos Network: +#### An open and decentralized network for Big Data and training models. + +Deitos Network aims to be a transparent, open, and decentralized platform dedicated to storage, data processing, modeling, and training. + +The network is designed to facilitate collaboration between various infrastructure providers and consumers in need of big data-related services. This encompasses data scientists from startups, academic institutions, and other organizations. Through this engagement, infrastructure providers will receive financial compensation for their services. + +The network allows processed and structured data to be utilized by AI and BI systems. This data can produce business analytics reports, predictive algorithms, clean datasets, and training sets, which can be used in different machine learning algorithms, analyses, and trend predictions. + +### Why develop blockchain? + +We believe that a network like the one we envision can democratize access to structured big data and AI model training. The model we propose is designed for a flexible market fit that can cater to diverse requirements. + +Blockchain technology offers a framework to create incentives for a decentralized network. This network can serve a public purpose by providing access to structured or trained data. + +### Why Polkadot SDK? + +Polkadot SDK is set to be the backbone of the network, orchestrating rewards, data interactions, disputes, consensus, and integrity checks. + +With the flexibility of Polkadot SDK, we can design a specific consensus algorithm that considers storage aspects, not just fund staking. On a broader scale, every infrastructure provider will operate a substrate node with an authoring role, and a minimum stake will be necessary to participate in the consensus. + +Utilizing Polkadot SDK allows us to implement runtime updates without causing forks or interruptions in the active network. + +### Why building Deitos Network? + +After thorough evaluation and research, our team identified a specific need and a viable solution. With extensive experience in the big data sector and a deep understanding of Polkadot SDK technology, we are confident in our ability to develop a robust project. We believe that using Polkadot SDK provides a solid foundation, as it is a leading technology for developing blockchains that aim to interoperate. + +# Project Details + +## Technology Stack + +- Polkadot SDK - Blockchain +- Hadoop - Distributed Storage Management +- Spark / Hive - Big Data processing tooling +- Llama v2 - LLM AI training model + +### Network actors + +#### Infrastructure Providers +These are entities responsible for providing the necessary infrastructure for all big data-related services. Additionally, they manage the substrate nodes that handle consensus-related operations. + +#### Consumers +As outlined in the project description, the user persona for this network encompasses any individual, entity, or organization requiring storage and computational resources for their data utilization. From the network's standpoint, these consumers are token holders who, alongside infrastructure providers, keep the network operational. + +#### Dispute Resolvers Committee +This group is tasked with resolving any disputes between consumers and infrastructure providers. Membership in this committee isn't static. Individuals must first nominate themselves, after which all token holders can vote within a specified timeframe to determine the nominee's inclusion. This election process is cyclical. + +### Network parties interaction flow. + +At a high level, when a consumer identifies an infrastructure provider that best suits their needs, they enter into an agreement. This agreement is based on: +- The volume of storage to be uploaded and analyzed. +- The computational resources needed for data processing (e.g., vCores, RAM). +- The duration agreed upon for the above two parameters. + +Given these criteria, the consumer compensates the infrastructure provider incrementally, provided the service aligns with the mutual agreement's expectations. To ensure this, the consumer reserves a predetermined percentage of the total agreement value (also decided during the agreement). If there's a breach of contract, a dispute resolution process begins, involving the Dispute Resolvers Committee. They determine if a party has defaulted, be it an infrastructure provider not delivering the agreed resources or a consumer raising unfounded complaints. Upon resolving the dispute, appropriate penalties are enforced, and the dispute resolvers receive compensation for their mediation efforts. + +### On-chain reputation system +After the conclusion of each agreement, participants can review their counterpart. This feedback contributes to an on-chain reputation system, fostering more secure interactions as the network evolves. However, in the event of disputes, neither party can leave feedback. Instead, the dispute's outcome is recorded in their respective profiles. + + + +## Architecture Overview + +![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 + +- **Hector Bulgarini**: Senior Software Developer and Team Lead +- **Hernan Borelli**: Product & Project Manager +- **Ramón Valera**: Data Sciense specialist & Senior Software Developer +- **Alexander Kalankhodzhaev**: Senior Blockchain and protocol Engineer + +### Contact + +- **Contact Name**: Hernan Borelli +- **Contact Email**: hernanbor@gmail.com + + +### Legal Structure + +- **Registered Address**: To be provided privately. +- **Registered Legal Entity**: To be provided privately. + +### Team's Experience + +**Hector**: With over 15 years in the technology sector, Hector focused on blockchain and Polkadot tech stack evidenced by his work at Parity and the graduation from the first Cambridge cohort of the Polkadot Academy. Hector also have founded and led multiple startups showing a strong entrepreneurial spirit. + +**Hernan**: Hernan holds a degree in project management and development. Since 2020, he has been deeply involved in promoting and developing the Polkadot ecosystem in Spanish-speaking countries. + +**Ramon**: Ramon is a software engineer with 18 years of experience in a wide range of work areas and applications. His professional career has ranged from the design and development of large-scale enterprise and web applications, to document and database systems management, in addition to application integration and Big Data solutions. In recent years, he has specialized in solving challenges related to Big Data and Application Integration, facing problems of nature and volume of data, as well as performance and efficiency for optimal results. + +**Alex**: With a rich experience spanning over 15 years as a software engineer, Alex has worked across various companies and domains. For the past 5 years, he has specialized as a blockchain engineer. Alex is a significant contributor to a substrate node developed in Java, which can be found here: [substrate-client-java](https://github.com/strategyobject/substrate-client-java). + +Additionally, he currently maintains GO-LINQ, a language integrated query (LINQ) library for Go. More about it can be found here: [GO-LINQ](https://github.com/ahmetb/go-linq). + + +### Team Code Repos + +- [Deitos network](https://github.com/Deitos-Network) +- Ramon: https://github.com/rvalera +- Alex: https://github.com/kalaninja +- Hector: https://github.com/hbulgarini + +### Team LinkedIn Profiles + +**Linkedin profiles** +- Hector: https://www.linkedin.com/in/hector-esteban-bulgarini-0791147 +- Ramon: https://www.linkedin.com/in/ramonvalera +- Hernan: https://www.linkedin.com/in/hernan-borelli-62296261 +- Alex: https://www.linkedin.com/in/kalaninja/ + +## Ecosystem Fit + +The Polkadot ecosystem is known for its integration of a myriad of projects, each offering distinct functionalities. These projects often interoperate with one another and frequently rely on external data to achieve their objectives. Our primary aim is to supply blockchain-validated, processed big data for various systems and applications that necessitate this kind of information. + +**Target Audience** + +While structured big data caters to a diverse range of users and applications, Deitos Network is specifically tailored to develop a system and user experience (UX) optimized for Artificial Intelligence (AI) and Business Intelligence (BI) applications. + +**Problem Statement** + +The digital realm is witnessing an unprecedented surge in data, leading to challenges in hosting, structuring, analyzing, and processing this vast amount of information. Various entities, from businesses and governments to scientists and other professionals, are in dire need of this data for a plethora of applications. However, they often grapple with limitations in accessing and utilizing it effectively. The exponential growth of big data far outpaces our current capacity to process it, resulting in a vast reservoir of unstructured data that remains untapped for many potential applications. The intricate process of structuring and analyzing this data demands immense computational power, further constraining its effective use. + +On the flip side, fostering a diverse ecosystem of big data storage, management, and processing providers can offer users solutions that are more attuned to their specific needs and requirements. + +**Similar Projects in the Ecosystem** + +In the realm of data storage and processing, two notable projects are making strides in the development of decentralized networks: + +- **Subspace**: This project is geared towards addressing the blockchain trilemma. Its primary feature revolves around the development of a Secure & Sustainable Consensus, specifically the Proof-of-Archival-Storage (PoAS) consensus. Among its other salient features, it emphasizes full decentralization and composite scaling. + +- **Cess**: Positioned as a Large-Scale Decentralized Cloud Data Solution, CESS's Decentralized Cloud Network is fine-tuned for processing high-frequency dynamic data. It facilitates real-time data sharing while ensuring the protection of users' data ownership, privacy, and assets. + +- **Arweave**: A decentralized storage network designed to offer permanent data storage. + +While Deitos Network shares similarities with platforms such as Crust, Arweave, and IPFS, Deitos primary focus is distinct. The network emphasizes the processing, structuring, and utilization of data. The direction leans more towards Big Data and AI functionalities than acting as a descentralized storage service. + +- **DecentralML**: A Polkadot protocol for decentralised federated machine learning and collective governance. + +Based on the grant information from [DecentralML](https://github.com/w3f/Grants-Program/blob/master/applications/decentral_ml.md), it appears there are parallels in terms of decentralizing machine learning model training, where rewards are based on data model training contributions and parameter adjustments by governance. + +Deitos approach, however, adopts a distinct architecture and game theory strategy. It focuses on infrastructure providers offering private services, competing to deliver optimal solutions to consumers. In future developments, these providers may also engage in maintaining and utilizing a shared public dataset, rewarded for hosting this data and processing consumer requests. (Section added from application's feedback). + +## Relevant prior work and research on the topic + +Some of the following topics/reads were analyzed and processed: + +- [BlockHDFS: Blockchain-integrated Hadoop distributed file system for secure provenance traceability](https://www.sciencedirect.com/science/article/pii/S2096720921000270) +- Trusted Execution environment +- Proof of Space +- Shamir’s Secret Sharing +- Distributed Key Generation +- Subspace + +## Development Status :open_book: + +Our team has been diligently exploring various cryptographic primitives and experimenting with different substrate configurations to progress towards a Proof of Concept (PoC). +These can be found in the Github organization. + +## Development Roadmap :nut_and_bolt: + +### Grant Scope + +This grant is specifically earmarked for the foundational development of the network. Once the foundational elements, such as the substrate node and runtime, are established, the grant's focus will shift towards the development of the Infrastructure Provider Management module, Proxy,the Data Integrity Protocol and the disputes mechanism. This can also be perceived as the mechanisms for authentication, data upload, and integrity verification. + +Elements related to data consumption or querying, as well as the inclusion of other computational resources like vCPUs and RAM within the agreement, fall outside the purview of this grant. These aspects are slated for consideration in future development phases. Additionally, there are certain security implications associated with the Data Integrity Protocol and data consumption. Addressing these will necessitate advanced privacy measures, potentially involving zero-knowledge proofs. + + +### Overview + +- **Total Estimated Duration:** 12 weeks (3 months). +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 30.000 USD + +### Milestone 1 — Initial setup and infrastructure provider pallet. + +- **Estimated duration:** 6 weeks +- **FTE:** 3 +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | The project will utilize the GNU General Public License v3 (GPLv3) license. | +| **0b.** | Documentation | All the functionalities developed in this milestone will contain the corresponding inline code documentation. In addition, all the configuration for the services included in the Infrastructure Provider will be documented. | +| **0c.** | Testing and Testing Guide | 1) All the different pallets and functionalities will contain their own unit testing contained in the `test.rs` files including the inline documentation for each test purpose. 2) Comprehensive testing guide for interacting with all the functionalities from the `pallet-deitos`. 3) User guide to start the Docker file provided in the delivery item **0d.**| +| **0d.** | Docker file | 1) Provision of a Docker file encapsulating all essential services. 2) Streamlined deployment of services: Hadoop, Spark, Hive, YARN, Llama v2, and the substrate node. 3) A docker-compose file to simplify onboarding and integration for providers. | +| 1. | Substrate Node with BABE consensus | 1) Reconfiguration of the node to employ the BABE consensus protocol in place of the Aura consensus. 2) Integration of the respective VRF setup for BABE consensus. 3) Proper configurations on the node side like integrating the `BabeBlockImport`, initiating BABE workers, and setting inherents from `sp_consensus_babe` on the node service.rs file beyond just embedding the pallet-babe in the runtime| +| 2. | Pallet Deitos foundation (pallet-deitos) | 1) Introduction of foundational elements of the pallet, incorporating storage items for cataloging Provider data, the specifics of agreements between Providers and Consumers, the reputation system and the data integrity protocol. 2) Framework scaffolding for future enhancements. 3) Groundwork for the data integrity protocol to be executed by this pallet's off-chain worker. | +| 3. | Registration of Infrastructure Provider (pallet-deitos) | 1) Mechanism for infrastructure provider registration within the pallet-deitos. 2) Requirement of reserving a certain amount of funds. 3) Groundwork for attestation process initiation for new entrants. This will be completed in the next milestone with the data integrity protocol. | +| 4. | Agreements Module (pallet-deitos) | 1) Functionality to define agreements between users and infrastructure providers. 2) Outline of storage quotas and its duration based on block by block reward dynamics. 3) Introduction of pertinent extrinsics, storage components, and events for agreements. 4) Mechanism where the consumer reserves a value based on the agreement's terms, leveraging either the ReservedCurrency trait from pallet-balances or the MutateHold trait from Fungibles depending of the pallet-balances migration status. | +| 5. | Agreements termination and on-chain reputation (pallet-deitos) | 1) Termination agreement procedure where consumer's data and corresponding resources get free from the infrastructure provider. 2) Data Integrity protocol clean up. 3) On chain reputation module based on feedback from the other party. | + +### Milestone 2 — Proxy, file uploader and data integrity protocol. + +- **Estimated duration:** 6 weeks +- **FTE:** 3 +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | The project will utilize the GNU General Public License v3 (GPLv3) license. | +| **0b.** | Documentation | Building upon the documentation provided in the first milestone, this milestone will introduce a new set of user guidelines. As the grant approaches its conclusion and all implementation details are settled, we will provide thorough protocol documentation. | +| **0c.** | Testing and Testing Guide | 1) All the different pallets and functionalities will contain their own unit testing contained in the `test.rs` files including the inline documentation for each test purpose. 2) This milestone will deliver the necessary tools to establish a local testing environment, allowing for comprehensive testing of all functionalities. | +| **0d.** | Docker | As we plan to deliver the software to infrastructures providers (IP) in docker images, all the protocol services will be configured and delivered in the IP Docker image. | +| **0e.** | Articles | For the grant conclusion we will create two Medium articles: The first one will be a project introduction targeting a more general and wide audience. Some of the content will include: 1) Deitos Network introduction and network offering, 2) Roles and protocol functioning, 3) Design decisions. On the second article, we will delve into more technical information where the development aspect of this grant will be discussed. The audience for this second article will be more technical and the following items will be discussed: 1) Architecture in depths, 2) Substrate pallets descriptions, 3) Internal functioning of each module. | +| 1. | Proxy Development | 1) Complete development and deployment of the described proxy ensuring interaction between infrastructure providers, consumers and the substrate node. 2) Mechanism to reserve resources on the infrastructure provider for a consumer upon agreement commitment. 3) A system focused on storage where user segmentation is achieved through dynamic users generated on Hadoop. 4) Authentication derived from a signed transaction initiated by the pallet-deitos pallet. 5) Development of a module to validate consumer signatures and commit actions upon successful verification, ensuring no traditional passwords are stored in the system. | +| 2. | File Uploads (Client Interface) | 1) Delivery of a client interface to facilitate file content splitting and hash calculation. 2) Creation of a generic algorithm to uniformly split files and calculate segment hashes. 3) Mechanism for producing and publishing signed transactions reflecting the computed results.| +| 3. | File Upload Verification (Provider Side) | 1) Using the previously generic algorithm to uniformly split files and calculate segment hashes for each file or part upon receiving the consumer's signed transaction. Files are marked as 'verified' post successful hash validation. 3) Constant monitoring of blocks to detect unverified files, triggering an OCW for hash verification based on consumer transactions. | +| 4. | Data Integrity Protocol | 1) Comprehensive development and deployment of the Data Integrity Protocol. 2) Utilizing BABE-generated randomness to select files/parts, directing infrastructure providers to create and validate respective hashes. 3) In case of hash mismatches during the data integrity protocol, a system to penalize the provider by reducing their staked amount. | + +## Mid-Term Plans + +### High-Level Overview roadmap. + +1) Development of the storage layer and data model foundations, which is the current grant's focus. +2) Addition of the execution aspects for agreements and the dispute resolution mechanism. +3) Implementation of security measures such as infrastructure provider attestation to ensure execution integrity and reliability. + +- Further development of the network's roadmap, which includes: + - Deliver a on-chain dispute resolving module in case of disagreements between consumers and infrastructure providers (Stage 2). + - Introducing data consumption processes, such as querying or interacting with the model (Stage 2). + - Implementing security mechanisms around the infrastructure provider to ensure the environment remains free from dishonest manipulations (Stage 3). + - Incorporating privacy primitives, like ZK proofs, to bolster data integrity and query processes (Stage 3). +- The aforementioned roadmap can be viewed as the essential MVP (Minimum Viable Product) for launching a test network, facilitating initial iterations. +- As we transition to a production phase, our plan is to secure core time, positioning us to join the Polkadot network as a parachain. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +Web3 Foundation Website / Medium / Twitter / Element / Announcement by another team / personal recommendation / etc. + +The team has a longstanding engagement with the ecosystem, making us well-acquainted with Web3 grants. diff --git a/applications/Diffy_chat.md b/applications/Diffy_chat.md new file mode 100644 index 00000000000..2999e71e599 --- /dev/null +++ b/applications/Diffy_chat.md @@ -0,0 +1,135 @@ +# Diffy messenger + +- **Team Name:** BelSoft +- **Payment Address:** Polkadot (Statemint): 14nQH1ZTDkRxLWdCWbSZjRGrBJpXgj4m2RRZDtQZExPP73K (USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: +This application complies with a potentially interesting project “Private instant messenger that uses on-chain identity” mentioned in [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source) page in the “Social Networking” section. + +## Project Overview :page_facing_up: + +A lot of sensitive data is meant to be transferred between parties in a secure way, but most of the centralized messengers and mail agents, even secured ones, have a common point of vulnerability - a centralized database/backend that stores all the data and manages connections. Meanwhile, some entities or even industries as a whole have demand for secured private channels for exchanging messages, e.g. medical institutions, that exchange sensitive data with patients or with other market players. + +The aim of this project is to develop a secured decentralized messenger that doesn’t store data on a centralized backend and uses personal Polkadot wallet credentials for chatting initiation and messaging. + +### Project Details + +P2p channels between users will be set using WebRTC. We will develop a Substrate pallet for exchanging [SDP offers](https://datatracker.ietf.org/doc/html/rfc2327). For address discovery of NAT users we will use any public [STUN server](https://datatracker.ietf.org/doc/html/rfc8445). +All messages between users will be encrypted with user’s public keys, so only receiving user could decrypt his messages using his private key of his Polkadot wallet. +Also, the pallet will include a “contacts” feature: a user will be able to tie names to wallet addresses and organize his contacts in a common way. + +![image](https://user-images.githubusercontent.com/126072104/220610232-0b9a4033-97cc-44ba-8948-a610b2b0c4bf.png) + +### Ecosystem Fit + +The Diffy chat dapp is very in demand in areas where it is crucial to protect personal and other critical data from unauthorized access during interaction or communication between counterparties. The target audience is very wide: from medical institutions providing telemedicine services to remote financial services and corporate channels for transmitting sensitive information between remote divisions. + +In the [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source) we see the [Uke Protocol Pallet](https://github.com/Uke-Messaging/uke-pallet) project, that provides functionality to perform basic messaging and identity assignment to users on a given Substrate chain. Unlike Uke Protocol, Diffy chat dapp won’t use a blockchain for sending and storing entire messages as in case of mass use this feature will dramatically clog the blockchain with unnecessary information like "hello" messages. Our dapp will use a blockchain just for authorization purposes, p2p connection initiation and for personal encryption keys. History backup feature can be available on later stages of the project by storing files locally or in IPFS with putting just a hash sum in a blockchain. + +## Team :busts_in_silhouette: + +### Team members + +- Max Remov, managing partner at BelSoft Dev d.o.o +- Alexey Vexin, CEO at BelSoft Dev d.o.o +- Dmitrii Shevchenko, CTO at BelSoft Dev d.o.o +- Nikita Orlov, Teamlead at BelSoft Dev d.o.o +- Alexander Plekhanov, Middle full stack developer at BelSoft Dev d.o.o +- Valeriy Tetevin, Senior full stack developer at BelSoft Dev d.o.o + +### Contact + +- **Contact Name:** Alexey Vexin +- **Contact Email:** vexin@belsoft.rs +- **Website:** https://www.belsoft.rs + +### Legal Structure + +- **Registered Address:** Kneza Mihaila 33, sprat 2 , Stari Grad , 11000 Beograd , Srbija +- **Registered Legal Entity:** Belsoft Dev DOO Beograd + +### Team's experience + +Max Remov is a business and personality transformation expert, executive and visionary, innovation instigator across telecom, retail, chemistry, pharma. Participates in several crypto initiatives. + +Alexey Vexin is product owner and project manager with 10+ years of experience in managing complicated telecoms and IT projects in Telco, Utilities and Governmental sectors with deep focus on business process management. Led dozens of federal scaled projects for IT systems implementation and industry scaled technology development, standardization and implementation. + +Dmitrii Shevchenko is a TechLead engineer with 10+ years of experience in developing and integrating IT, networking, security and blockchain solutions. Involved in implementation of highly reliable industrial solutions and development of FinTech and DeFi applications. + +Nikita Orlov, ETH Waterloo 2019 hackathon prize-winner, is a TechLead engineer with over 8 years of experience in development and integration of fault-tolerant high-loaded SaaS IT solutions including relevant experience in blockchain solutions. + +Alexander Plekhanov is a full stack software developer with over 5 years of experience including blockchain-based projects, enterprise solutions for fintech, call-centers, government services. Recent time mostly focused on smart-contracts development. + +Valeriy Tetevin is a programming engineer with over 8 years of experience in cloud-native applications. He also has strong knowledge of microservices architecture and back-end development for high-loaded applications. + +### Team Code Repos + +- https://github.com/1db1 +- https://github.com/StringNick +- https://github.com/SealTV + +### Team LinkedIn Profiles (if available) + +- [Max Remov](https://www.linkedin.com/in/remov) +- [Alexey Vexin](https://www.linkedin.com/in/alexey-vexin-800a4068/) +- [Nikita Orlov](https://www.linkedin.com/in/nikita-orlov-aa6910186/) +- [Alexander Plekhanov](https://www.linkedin.com/in/alexander-plekhanov/) +- [Valeriy Tetevin](https://www.linkedin.com/in/sealtv/) + +## Development Roadmap :nut_and_bolt: + +We plan to execute 3 deliverables in two milestones: +- a Substrate pallet for chat initiation; +- a DOTRTC library for p2p transport implementation with test html pages for message passing; +- a web-messenger dapp MVP with polkadot wallets authorisation. + +The project will be supported by a team of 2 developers, 1 UI/UX designer, 1 DevOps engineer and 1 QA. + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 3,5 FTE +- **Total Costs:** 30,000 USDT + +### Milestone 1 — Design and development of a pallet and a DOTRTC library + +- **Estimated duration:** 1,5 months +- **FTE:** 2 +- **Costs:** 16,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 the developed features work. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure new functionality and robustness. In the guide, we will describe how to run these tests. | +| 1. | Diffy chat pallet | We will develop a pallet (using Rust) which will include event handling to send and approve WebRTC offers for chat initiation. | +| 2. | DOTRTC library | We will develop a DOTRTC library (with JS) for p2p transport implementation using a parachain with Diffy chat pallet. This library will include an API for organizing p2p communication, methods for splitting packets into chunks (and reassemble on the receiver’s end). For secure messaging between two participants a e2e encryption using the rs25519 algorithm will be implemented in the DOTRTC library (a sender will encrypt outgoing messages with recipient’s public key so only the recipient could decrypt them with his private key). | +| 3. | HTML test page | We will deliver an HTML test page for DOTRTC library testing (setting a p2p channel between 2 users using the DOTRTC library). | + +### Milestone 2 — A web messenger MVP development + +- **Estimated duration:** 1,5 months +- **FTE:** 1,5 +- **Costs:** 14,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 the new dapp works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Article | We will publish an **article** that explains what was achieved, how to use the new Dapp and what benefits what are the benefits of using the system | +| 1. | Contacts list feature | We will develop a contact list feature allowing users to tie real names to contact’s wallet addresses and store them encrypted in a blockchain. Encryption and decryption will be carried out on the frontend. | +| 2. | Web messenger dapp MVP | A web messenger dapp (written on JS) with authorization via Polkadot.js keys, p2p messaging using developed DOTRTC library and contacts list: a user will be able to start a conversation with someone on his contacts list. A web dapp MVP mockup is shouwn below and the basic user logic is as follows. To establish a chat User A sends a short 1st message to User B (limited to 50 symbols as it is written into the blockchain). This message is sent with the connection request. When User B is on-line he receives this message with connection request and accepts it: automatically for users on his contact list and manually for requests from unknown users (connection request can be declined as well).| + +![Diffy_chat mockup](https://user-images.githubusercontent.com/126072104/223709096-ccec2425-f3ac-4c8f-853f-d3656a8c29c5.jpg) + +## Future Plans + +In the next stages of the project we plan to implement new fundamental features like: +- offline messaging; +- group chats (p2mp); +- sending/receiving files; +- chats backup feature. + +These should be developed under later stages of the project. diff --git a/applications/DipoleOracle.md b/applications/DipoleOracle.md index c94d3c19bf5..3159a93cfb1 100644 --- a/applications/DipoleOracle.md +++ b/applications/DipoleOracle.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Dipole Oracle -* **Project:** Dipole Oracle * **Proposer:** [KK](https://www.linkedin.com/in/kaikai-yang) diff --git a/applications/DistributedKeyManagement.md b/applications/DistributedKeyManagement.md new file mode 100644 index 00000000000..93874d444ad --- /dev/null +++ b/applications/DistributedKeyManagement.md @@ -0,0 +1,144 @@ +# Distributed Key Management + +- **Team Name:** Jett Hays (Individual) +- **Payment Address:** 0x33644e4D6bb589854fbb906276147Afd7de86E09 (ERC-20 USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + +### Overview + +This project will explore the security and applications of using secret sharing to distribute wallet ownership. + +Public key cryptography has enabled encrypted communication and global computing protocols like Polkadot. +But managing keys is hard. Existing noncustodial key management solutions require memorizing long mnemonic phrases, using network specific smart contracts, +or purchasing complicated hardware wallets. These solutions are insufficient for the majority of users who are looking for a simple way to manage private keys. +This grant will support research on a distributed key management system and an open source reference implementation. +If successful, this project will help make Polkadot hot wallets more secure and simplify online ownership. +With the proposed system, wallets could implement 2fa and authenticate with their existing Google or Apple account. + +I believe wallets are the connection point between users and the decentralized web. Making this connection point accessible and secure is incredibly exciting and drives my interest in developing this project. + +### Project Details + +This is a research project focused on distributed key management. The basic idea involves sharing a secret– in this case, a BIP32 seed phrase– between a client and remote servers. When the private key is needed, the shares are reassembled on the client and used within a standard key manager. The local key manager can then be used to publish transactions, encrypt data, validate identity, etc. I have already implemented a version of this idea within the open source Kryptik wallet. However, more research is required to answer essential security questions (discussed in the project timeline) and provide a common reference implementation. A skeleton of the distributed key management system, as implemented by the Kryptik wallet, is described below. + +##### Client Seedloop + +Wallets are derived from a single parent key. This parent key is used as a seed to generate a child key for each blockchain network, in accordance with the BIP 32 specification for hierarchical deterministic wallets. Child keys may produce an array of addresses and have custom methods depending on the network type. This cluster of keyrings is stored on a single seed loop object that contains the parent key. The seedloop can be encrypted with a standard password by the user at any point in time. + +##### Local Storage + +When a wallet is created, the wallet object is serialized, encrypted, and stored in the browser’s local storage. The random encryption secret is then split with shamir secret sharing into two shares. One share is held locally and one share is sent to the database. When a new user session begins, the service retrieves the database share and combines it locally into the original encryption secret. The wallet can then be decrypted, deserialized, and made available for use. This arrangement results in a two-of-two security scheme, where an attacker must compromise both systems to obtain a user’s private seed. + +##### Authentication + +Kryptik uses a decentralized authentication provider to generate a user identifier which is passed to the user through a ‘magic’ link sent via email. The ID is then exchanged with the database for an access token and the user session begins. + +##### Conclusion + +This system has worked well during public testing. However, improvements must be made to generalize beyond a 2 of 2 system– this has potential implications for social recovery– and research must be conducted to understand the security implications of distributed key management as described above. This project will accomplish both of these goals in addition to providing a common reference implementation. + +### Ecosystem Fit + +Secure and usable key management is an open issue. This project will improve the security of hot wallets– through encryption, 2fa, and distributed secret sharing– and provide users with a simple key management flow: just authenticate like you would for any other app! + +The initial research will be used to improve the distributed key management implementation currently used by the Kryptik wallet. However, the research, code, and documentation are designed for the broader developer community to use in their own app that supports Polkadat or Kusama. + +## Team :busts_in_silhouette: + +### Team members + +Leader: Jett Hays +Advisor: Nicolas Christin + +### Contact + +- **Contact Name:** Jett Hays +- **Contact Email:** jehays@andrew.cmu.edu +- **Website:** [jetthays.com](https://jetthays.com/) + +### Legal Structure + +Individual / Sole Proprietor + +### Team's experience + +Jett Hays is the President of the Carnegie Mellon blockchain club where he helps members build and understand the decentralized future. Previous projects have included a open source key management package[https://github.com/KryptikApp/kryptik-seedloop] and a [multichain web wallet](https://www.kryptik.app/). Both projects have received support from Carnegie Mellon and multiple blockchain foundations. + +### Team Code Repos + +- https://github.com/KryptikApp +- https://github.com/KryptikApp/kryptikwebapp +- https://github.com/KryptikApp/kryptik-seedloop + +- https://github.com/jettblu + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/jett-hays-491b541b7/ + +## Development Status :open_book: + +The idea of a distributed key manager came to me during a class at Carnegie Mellon on shamir secret sharing. After coming up with a rough interface, I applied for a small undergraduate research grant from CMU, with Professor Nicolas Christin agreeing to be my advisor. +This research led me to create the open source Kryptik wallet, whcih I have been working on for the past year. A short demo of the wallet can be found via [this link](https://vimeo.com/745609041). This wallet uses a simple version of the distributed key management system I described above. + +As part of this project, I also released a seedloop manager as an open source NPM package, which can be found [here](https://github.com/KryptikApp/kryptik-seedloop). This package allows developers to easily generate wallets and sign transactions across multiple blockchains. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** .4 FTE +- **Total Costs:** $8,000 + +### Milestone 1 - Research Paper + +- **Estimated duration:** 10 weeks +- **FTE:** 0.4 FTE +- **Costs:** 5,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide regular blog updates that document our discoveries on decentralized key management as we develop the paper. | +| 0c. | Testing and Testing Guide | Since this milestone is focused on creating and publishing a research paper, there is no need for a testing guide. | +| 0d. | Docker | This milestone does not involve explicit software, so no dockerfiles are needed for testing. | +| 0e. | Article | We will publish an article that summarizes the key findings of our distributed key management research for developers (who may not be interested in the nitty gritty technical details or security models). | +| 1. | Formal Investigation | The research period will be spent investigating the following questions about the kryptik key management system. What is the threat model? How can keys be synced across devices? How can the system include more than two shareholders? What is the ideal number of shareholders? Is there any application to social recovery? By the end of this period, I will have organized a sequence of proofs and thoughts that can be shaped into a paper. Each question and associated discovery will be documented via regular blog posts.| +| 2. | Research Paper | This paper will include an in depth analysis of the research questions discussed above. Professor Nicolas Cristin of Carnegie Mellon will help advise the paper– he served as an advisor for my initial research grant from CMU. The paper will be released as an open source document on Github. We expect this open source key management knowledge to provide a strong foundation for future Polkadot/Kusama/Substrate wallet designers.| + +### Milestone 2 — Reference Implementation + +- **Estimated Duration:** 1 month +- **FTE:** .4 +- **Costs:** 3,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide extensive inline documentation that describes the purpose of functions and parameters. This will help create a 'trail of knowledge' that developers can follow through the key management system.| +| 0c. | Testing and Testing Guide | We will include a step by step guide that shows the distributed key management system works as intended. Unit tests will be included for critical functions like share generation/ recombination. Unit tests will be executed using vitest. | +| 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 provides a step by step explanation of the distributed key management system and how each function is implemented in code. This will be published as a blog post. | +| 1. | Vault Module | The vault module will provide a standard interface for storing a BIP 39 seed and multiple blockchain accounts on the client.| +| 2. | Encryption Module | The encryption module will allow seed vaults to be locked/unlocked via a user provided password. The module will also use a randomly generated encryption key to create ciphertext for the BIP39 seedphrase when persisting vault storage on the client.| +| 3. | Share Module | The share module will generate shamir shares for a given piece of data (in this case the encryption secret). This module will also allow shares to be recombined (according to the k of n secret sharing scheme) to reconstruct the original piece of data. | +| 4. | Sync Module | This module will allow seed vaults to be synced across devices.| +| 5. | Web Deployment | And finally, we will wrap these modules in a nice UI and deploy the interface to a website (likely using NextJs + Vercel). This website will allow developers to create a vault, sync their devices, and sign sample transactions. This will be accomplished via open source React components that developers can reuse in their own application. The deployed app will have Polkadot/Kusama/Substrate specific examples (address generation, signatures, etc) that will benefit future developers.| + +## Future Plans + +After the grant is completed, I will continue improving the open source Kryptik wallet, which builds upon the distributed key management system described above. Work on the wallet interface– which has been sponsored by other grants– will necessarily include revisiting the key management system and making improvements (such as adding the ability to sync key shares between devices). Beyond that, the research and published paper are a timeless body of knowledge that will continually benefit production implementations and new research on key management. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** I first heard about the grants program at EthDenver 2022. I then learned more about the program via the Web3 Foundation Website. + +The NEAR foundation awarded a $45,000 grant to develop the Kryptik wallet interface. This work wrapped the key management system with software that supports multi chain swaps, collectibles, payments, etc. I also received $20,000 from the Solana Foundation to provide open source documentation and Solana specific examples. Both of these grants are directed towards the Kryptik wallet interface, not the key management system which was devised separately. + +Finally, I received $500 from Carnegie Mellon to build the key manager and host the wallet interface. + +**How does this project benefit the Polkadot/Kusama/Substrate ecosystem? +Asymmetric key management is an open issue that affects every blockchain ecosystem. An improved key management system will help improve wallet design which, in turn, will help improve the user experience of the Polkadot/Kusama/Substrate ecosystem. The research proposed above will provide foundational knowledge and software that can be integrated into existing Polkadot related wallets and in emerging wallets that have yet to be designed. In summary, successful execution of the grant will result in a simple and more secure way to interact with the Polkadot/Kusama/Substrate ecosystem. This will benefit users, who will have an improved wallet experience, and developers who can build upon a novel approach to key management. diff --git a/applications/DotPay.md b/applications/DotPay.md index 1bd7a29e9b4..f1d7ba0bf4d 100644 --- a/applications/DotPay.md +++ b/applications/DotPay.md @@ -1,6 +1,5 @@ # DOT PAY -- **Project Name:** DOT PAY - **Team Name:** Crypto Pay Lab (CPL) - **Payment Address:** 3CnxDH6myTaK6MVy3SawVF2FC6FdgfK8pj （BTC address） - **[Level]:** 2 @@ -9,19 +8,18 @@ #### Why Dotpay -Many developers love open source very much, but they have no way to devote themselves to the construction of open source, +Many developers love open source very much, but they have no way to devote themselves to the construction of open source, because they can't get enough compensation for users' lives in the process of contributing to open source projects, so they must be employed by a certain company. -We hope to use the power of blockchain to change this status quo. +We hope to use the power of blockchain to change this status quo. -The owner of an open source project can initiate paid tasks, and developers can complete tasks to get paid. +The owner of an open source project can initiate paid tasks, and developers can complete tasks to get paid. -Note that it is not a tip. This will allow more power to participate in open source projects and make open source projects better. +Note that it is not a tip. This will allow more power to participate in open source projects and make open source projects better. The development of the company generates greater value, and then more funds can be used to pay developers to form a virtuous circle. - #### What is Dotpay DotPay is a platform that supports paid tasks to complete open source projects on Github. @@ -42,13 +40,13 @@ Page 2: Configure Github webhook Page 3: Recharge ![image](https://user-images.githubusercontent.com/94216827/142724518-a22d1760-eeb8-4399-b0ac-e04348002beb.png) -Page 4: Creat tasks and trigger the payment +Page 4: Creat tasks and trigger the payment ![image](https://user-images.githubusercontent.com/94216827/142757369-7bb816ae-b834-4a80-a562-8bb21da0624f.png) Page 5: Bind reward address -If the developer has not bound the address before, -the system will prompt him to use the following instructions to bind, +If the developer has not bound the address before, +the system will prompt him to use the following instructions to bind, just reply to similar instructions like `/dotpay bind [address]` in the issue corresponding to the task ![image](https://user-images.githubusercontent.com/94216827/145700577-bb02ef26-cebd-4516-bc9b-772a90f36b68.png) @@ -60,6 +58,7 @@ just reply to similar instructions like `/dotpay bind [address]` in the issue co DotPay is a payment platform, you can initiate open source tasks and paid with DOT tokens (for example, you can initiate paid collaboration tasks when you encounter difficulties in architecture construction, requirements analysis, document construction and testing). Those who complete the tasks as required can receive tokens after the task initiator verifies that the tasks are completed The specific process is as follows: + 1. Alice recharge Dot tokens on the platform. 2. Alice initiates paid open source tasks on the Github (such as the task about architecture construction, requirements analysis, document construction, development and testing, etc ) 3. Bob accepted this task on Github and completed it! @@ -112,16 +111,16 @@ Command line in issue reply: `/pay Bob 10DOT` ### An overview of the technology stack to be used -* Font-end, typescipt,react -* Backend, golang,Rust -* Devops, github action, kubenretes -* Search, MeiliSearch +- Font-end, typescipt,react +- Backend, golang,Rust +- Devops, github action, kubenretes +- Search, MeiliSearch ### Key Functions 0. User management - - Using github OAuth2 login, user group management. - + - Using github OAuth2 login, user group management. + 1. Email / Issue informal - Imformal user to withdraw their DOT tokens. @@ -138,40 +137,39 @@ Command line in issue reply: `/pay Bob 10DOT` 5. Issue search - Users can find and filter paid collaboration tasks that meet their requirements in the issue search form. -6. Payment secrect management +6. Payment secrect management - Create it on DotPay website and config it to github secrect to pay user DOT. - + 7. Recharge & transfer by ink! contract -* Set the maximum amount and maximum total amount for each transaction +- Set the maximum amount and maximum total amount for each transaction set_limit(per_transfer_amount, total_transfer_amount) Only the owner of the project has the calling permission -* Set up the transfer whitelist +- Set up the transfer whitelist set_witelist(username, address) Only the owner of the project has the calling permission -* Transfer interface +- Transfer interface transfer(address,amount) The platform has the calling permission Benefits of this design: -* The platform no longer needs the owner to recharge, just need to sign a contract with the owner -* The platform does not have the authority to set a whitelist, ensuring that the platform cannot transfer funds to addresses other than the whitelist set by the owner -* The single maximum amount and the total amount set to a certain extent ensure the safety of the owner's funds - +- The platform no longer needs the owner to recharge, just need to sign a contract with the owner +- The platform does not have the authority to set a whitelist, ensuring that the platform cannot transfer funds to addresses other than the whitelist set by the owner +- The single maximum amount and the total amount set to a certain extent ensure the safety of the owner's funds ### Ecosystem Fit -As far as I am concerned, there are no similar projects in Polkadot ecosystem. +As far as I am concerned, there are no similar projects in Polkadot ecosystem. Maybe we have some similarities with dotmarket, there are still many differences to compare with dotmarket, dotpay will focus on open-source payment collaboration, deep integration with GitHub, closer to end-users， -what's more important is we prefer to realize open source payment cooperation in Polkadot ecosystem. +what's more important is we prefer to realize open source payment cooperation in Polkadot ecosystem. -As we all know Polkadot offers flexible cross-chain interoperation functionality with a large user base and volume expectation, +As we all know Polkadot offers flexible cross-chain interoperation functionality with a large user base and volume expectation, and as a mainstream cryptocurrency with high market value, DOT tokens is easier for developers to accept and be recognized， @@ -181,56 +179,55 @@ And we also look forward to cooperating with dotmarket in the future. ## Team :busts_in_silhouette: -### Team members +### Team members We will pleased to offer github accounts, LinkedIn and any other information in private. All team members can contact privately for any specific information. -* Richard Fang: team leader, core developer +- Richard Fang: team leader, core developer -* Fugen Wang: Background development +- Fugen Wang: Background development - responsible for the development of the website background. -* Yang Li: +- Yang Li: - Responsible for front-end development. -* Peng Qiao: Rust developer +- Peng Qiao: Rust developer - Responsible for back-end development, relevant development of blockchain, payment task management module, and docking API and key management module on the chain. - -* Wei Zhang: +- Wei Zhang: - Responsible for operation, promotion in the open source community after the website is launched, and attracting open source projects to use our services. - -* AdaLam: PD/PMO + +- AdaLam: PD/PMO - Responsible for product design and project schedule management. - + ### Team's Experience -* Richard Fang: - - As an expert in the field of cloud computing in one of the biggested Internet listed companies with 7 years of rich working experience. - - The author of a well-known cloud native project which has more than 5K stars and 4k paid enterprise users. +- Richard Fang: + - As an expert in the field of cloud computing in one of the biggested Internet listed companies with 7 years of rich working experience. + - The author of a well-known cloud native project which has more than 5K stars and 4k paid enterprise users. -* Fugen Wang: - - CEO of an Internet start-up company and manages more than a dozen employees with 7 years working experience. +- Fugen Wang: + - CEO of an Internet start-up company and manages more than a dozen employees with 7 years working experience. -* Yang Li: - - Andriod/IOS front-end engineer with 5 years working experience. - -* Peng Qiao: - - A core member of AI Research Institute wich is one of the top AI listed companies in China with 5 years working experience. - -* Wei Zhang: - - An advertising director, one of the top AI listed companies in China with 7 years of rich working experience. - -* AdaLam: PD/PMO +- Yang Li: + - Andriod/IOS front-end engineer with 5 years working experience. + +- Peng Qiao: + - A core member of AI Research Institute wich is one of the top AI listed companies in China with 5 years working experience. + +- Wei Zhang: + - An advertising director, one of the top AI listed companies in China with 7 years of rich working experience. + +- AdaLam: PD/PMO - Familiar with product design and project schedule management. ### Contact - **Contact Name:** AdaLam - **Contact Email:** adalamlzy@gmail.com -- **Website:** comming soon +- **Website:** comming soon - **Contact Name:** Richard Fang - **Contact Email:** lamelegdog@gmail.com @@ -241,9 +238,9 @@ We will be pleased to offer specific information in private. ### Team Code Repos -https://github.com/bytepayment +https://github.com/bytepayment -https://github.com/bytepayment/bytepay +https://github.com/bytepayment/bytepay ### Team LinkedIn Profiles @@ -253,14 +250,15 @@ We will provid in private through Google Form. ### Overview -* **Total Estimated Duration:** 8 weeks -* **Full-time equivalent (FTE):** 5 -* **Total Costs:** 30,000 USD +- **Total Estimated Duration:** 8 weeks +- **Full-time equivalent (FTE):** 5 +- **Total Costs:** 30,000 USD ### Milestone 1 — User account management & repo management & mnemonic management + * **Estimated Duration:** 4 weeks -* **FTE:** 5 -* **Costs:** 15,000 USD +- **FTE:** 5 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -275,9 +273,10 @@ We will provid in private through Google Form. | 5. | Transfer ink! contract| We will provide an tested ink! contract on Substrate Smart Contracts Node, provide transfer limit, witelist and transfer function. The platform will integrate the contract when the Polkadot mainnet contract para chain is available. | ### Milestone 2 — Transfer module, task module, informal, withdraw module + * **Estimated Duration:** 4 weeks -* **FTE:** 5 -* **Costs:** 15,000 USD +- **FTE:** 5 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -290,8 +289,6 @@ We will provid in private through Google Form. | 3. | Withdraw module | Withdraw the DOT from our platform to developer own wallet, if developer bind it own address, payment will transfer to the account directly | | 4. | Informal | Developer will receive the event, tell him how to withdraw DOT in our platform, robot will send Bob email and comment the issue | - - ## Development Status https://github.com/bytepayment/bytepay @@ -302,17 +299,17 @@ Including GitHub webhook server，it can listen to GitHub events, handle some sp ## Future Plans -- About our future plan, we will support more payment scenarios, such as website recharge VIP and online payment to buy goods after completing this grant. -- And then, we are going to support more platforms to expand the number of users, not only completing paid tasks on Github , but also on Telegram, Discord, Twitter, etc, +- About our future plan, we will support more payment scenarios, such as website recharge VIP and online payment to buy goods after completing this grant. +- And then, we are going to support more platforms to expand the number of users, not only completing paid tasks on Github , but also on Telegram, Discord, Twitter, etc, and we also have an idea that cross-chain cooperation with other project. -- After that, We will launch our own Polkadot para-chain tokens and the open source developers will receive tokens by completing the paid tasks on Github. +- After that, We will launch our own Polkadot para-chain tokens and the open source developers will receive tokens by completing the paid tasks on Github. ## FAQ -> Why not use Paypal? +> Why not use Paypal? -Paypal has obvious borders for global developer collaboration, and it is not convenient to use. +Paypal has obvious borders for global developer collaboration, and it is not convenient to use. -In fact, we did similar attempts at the earliest and found that many countries do not use Paypal at all. +In fact, we did similar attempts at the earliest and found that many countries do not use Paypal at all. And we hope that open source paid collaboration More decentralized rather than relying on a certain company. diff --git a/applications/DotPulse.md b/applications/DotPulse.md new file mode 100644 index 00000000000..cabddeddbf0 --- /dev/null +++ b/applications/DotPulse.md @@ -0,0 +1,168 @@ +# DotPulse + +- **Team Name:** CrossChain Labs +- **Payment Address:** 0xC289B81a8e5f8F8d691b4Cf1DBc16A7107B630e3 (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + +### Overview + +Polkadot has increasingly grown the open source developer ecosystem. But there is currently no way to get an activity overview and easily track the development among different Polkadot organisations on Github, understand what is their status, track the contributions made by developers and get an idea on how the repositories evolve. Is really hard to understand how the Polkadot ecosystem is progressing since the data is scattered all over GitHub, with contributors, commits, issues, repositories and PRs data. + +The solution that CrossChain Labs presents is going to address the problems described above and will offer clarity on the open source Polkadot’s developer ecosystem. This will be done by scraping the data related to Polkadot’s organisations on GitHub and exposing it in a nicely designed dashboard that allows tracking the number of commits, repositories, contributors, PRs, the top contributors of the month, the evolution of commits and active contributors for each month over the last year and monitoring the recent commits that are being done in the various Polkadot organisations. + +### Project Details + +Deliverables: + +- GitHub Scraper that will collect all the required data from GitHub +- DotPulse APIs that will serve to get the data from the scraper and interact with the DotPulse dashboard +- DotPulse Dashboard that will include: + - the statistics top section with the overall number of commits, repositories, contributors and PRs + - contributors of the month + - commits graph with info regarding the last 12 months + - issues graph that shows the number of open and closed issues together with their total + - graph of active contributors for each month over the last year + - the recent commits section that shows the activity of the ecosystem over the last 30 days, with clickable links to open a commit, its repository or the developer's profile on GitHub + +Dashboard Overview + +DotPulse + +### Ecosystem Fit + +The DotPulse project will enable all the interested parties to track the development among different Polkadot organisations on Github, to follow the number of commits, repositories, contributors, PRs, the top contributors of the month, the evolution of commits and active contributors for each month over the last year and monitor the recent commits that are being done in the various Polkadot organisations. + +There are many benefits of getting the DotPulse project up and running: + +- it offers a clear overview on the open source development that is being done across the various Polkadot organizations, by having all the required data aggregated in one place +- acknowledges the contributors of the month +- displays the active contributors for each month over the last year +- shows the evolution of the number of commits made on GitHub by developers throughout the entire Polkadot ecosystem +- outlines the recent commits + +## Team :busts_in_silhouette: + +### Team members + +- Andreea - Team Leader +- Cristina - Full Stack Developer (JavaScript, React) +- Catalin - Full Stack Developer (JavaScript, React) +- Florin - UI/UX Designer (Sketch, Figma) + +### Contact + +- **Contact Name:** Andreea Stefan +- **Contact Email:** andreea.stefan@crosschainlabs.tech +- **Website:** https://www.crosschainlabs.tech/ + +### Legal Structure + +- **Registered Address:** Oaspetilor Boulevard, 15, Bucharest, Romania, #013865 +- **Registered Legal Entity:** CrossChain Labs SRL + +### Team's experience + +We’re CrossChain Labs, a team of of designer and software developers with hands-on experience on blockchain technology and development of decentralised applications, with previous experience as ConsenSys employees. Some of the latest dev-grants were for projects from Filecoin (https://filmarket.io/) and NEAR protocol (NEAR registrar, Audit Registry, near.link, Developer Dashboard) with tech stack: IPFS, Arweave, rust, react, go and javascript. +We're creative, experienced, responsible, organised and do our best to make high quality work and bring ideas to life. + +### Team Code Repos + +- https://github.com/CrossChainLabs +- https://github.com/CrossChainLabs/near-registrar +- https://github.com/CrossChainLabs/audit-registry +- https://github.com/CrossChainLabs/near-dns +- https://github.com/CrossChainLabs/near-api-go +- https://github.com/CrossChainLabs/coredns-near +- https://github.com/CrossChainLabs/near-link +- https://github.com/CrossChainLabs/filmarket-contract + +Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. + +- https://github.com/yellow-cube +- https://github.com/arctic-ash +- https://github.com/aliasccl + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/andreea-stefan-66740b20/ +- https://www.linkedin.com/in/cristina-varteniuc-6b3121224/ +- https://www.linkedin.com/in/catalin-vlad-48b828229/ +- https://ro.linkedin.com/in/florin-gradinaru-73891bb + +## Development Status :open_book: + +Since Polkadot has increasingly grown the open source developer ecosystem, there is a need to get an activity overview and easily track the development among different Polkadot organisations on Github, understand what is their status, track the contributions made by developers and get an idea on how the repositories evolve. Is really hard to understand how the Polkadot ecosystem is progressing since the data is scattered all over GitHub, with contributors, commits, issues, repositories and PRs data. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 8 weeks +- **Full-Time Equivalent (FTE):** 3 FTE, 1 PTE +- **Total Costs:** 42,000 USD + +### Milestone 1 + +- **Estimated duration:** 4 weeks +- **FTE:** 3.5 +- **Costs:** 20,500 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / MIT | +| 0b. | Documentation | We will provide both documentation of the code and a basic video tutorial that explains how a user can easily use DotPulse app | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 1. | Implement Github scraper functionality | Periodically update the list of repositories that are being part of the Polkadot organizations on GitHub | +| 2. | Implement Github scraper functionality | Calculate the total number of commits, repositories, contributors and PRs from the entire Polkadot ecosystem | +| 3. | Implement Github scraper functionality | Get the contributors of the month based on the number of commits | +| 4. | Implement Github scraper functionality | Calculate the total number of commits across all the repositories for each month over the last year | +| 5. | Implement Github scraper functionality | Collect the total number of issues that are being opened or closed at the moment | +| 6. | Implement Github scraper functionality | Calculate the number of active contributors for each month over the last year | +| 7. | Implement Github scraper functionality | Collect the list of recent commits across all the Polkadot's Github repositories from the last 30 days | +| 8. | Finalize the UX | With all its design elements +| 9. | Implement the DotPulse APIs required by frontend | Statistics API that returns the overall number of commits, repositories, contributors, PRs | +| 10. | Implement the DotPulse APIs required by frontend | Contributors API that returns the list of contributors of the month based on the number of commits over the last month | +| 11. | Implement the DotPulse APIs required by frontend | Issues APIs that return the total number of issues, the number of closed and open issues | +| 12. | Implement the DotPulse APIs required by frontend | Commits API that returns the total number of commits per month + +### Milestone 2 + +- **Estimated duration:** 4 weeks +- **FTE:** 3.5 +- **Costs:** 21,500 USD, +- NOTE: The M2 calculation includes the cloud infrastructure cost estimated at $1,000 + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / MIT | +| 0b. | Documentation | We will provide both documentation of the code and a basic video tutorial that explains how a user can easily use DotPulse app | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an article that explains what was achieved as part of the grant and how users can benefit the most from DotPulse functionalities. | +| 1. | Implement the DotPulse APIs required by frontend | Active contributors API that returns the number of active developers for each month over the last year | +| 2. | Implement the DotPulse APIs required by frontend | Recent commits API that returns the list of recent commits across all Polkadot repositories over the last 30 days | +| 3. | Build the DotPulse dashboard | Display the statistics top section with the overall number of commits, repositories, contributors and PRs | +| 4. | Build the DotPulse dashboard | Show the contributors of the month | +| 5. | Build the DotPulse dashboard | Commits graph with info regarding the last 12 months | +| 6. | Build the DotPulse dashboard | Issues graph that shows the number of open and closed issues together with their total | +| 7. | Build the DotPulse dashboard | Active contributors graph | +| 8. | Build the DotPulse dashboard | The recent commits section that shows the activity of the ecosystem over the last 30 days, with clickable links to open a commit, its repository or the developer's profile on GitHub | +| 9. | Prepare the final adjustments | Create the production infrastructure on Google Cloud | +| 10. | Prepare the final adjustments | Deploy dotpulse.io webapp | +| 11. | Prepare the final adjustments | Run the final tests | +| 12. | Prepare the final adjustments | Public release + +## Future Plans + +To drive adoption of the DotPulse platform, CrossChain Labs will: + +- create a YouTube video tutorial showcasing the DotPulse functionalities and usage +- distribute it via Polkadot Discord channels +- add Google Analytics to track users engagement in order to adapt and improve accordingly + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website / Friends & Colleagues diff --git a/applications/Doter.md b/applications/Doter.md index c0dc014a07b..238bd34a6e0 100644 --- a/applications/Doter.md +++ b/applications/Doter.md @@ -1,9 +1,7 @@ -# Open Grant Proposal - -* **Project Name:** Doter (A browser extension wallet for Polkadot) -* **Team Name:** ChainBridge network -* **USDT Payment Payment Address:** 0x9bb9af8f2fd4487c88f1352fdd32a3ec2b6d28b6(ERC20) +# Doter (A browser extension wallet for Polkadot) +- **Team Name:** ChainBridge network +- **USDT Payment Payment Address:** 0x9bb9af8f2fd4487c88f1352fdd32a3ec2b6d28b6(ERC20) ## Project Overview @@ -15,11 +13,14 @@ We are committed to building Doter into a truly user-centric browser extension w Now, we can already [install Doter](https://chrome.google.com/webstore/detail/doter/abamjefkidngfegdjbmffdmbgjgpaobf) in the Google Chrome extension market. -### Project Details +### Project Details #### Functional structure + ![img](https://uploader.shimo.im/f/4XnoevPmkhO6ZSqT.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTkxMzk5MDEsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE5MTM4MTAxLCJ1IjowfQ.gkX36NMe-V9je08Ofh2mFgSEzsJ_k-YnHBsaVxo2Lyo) + #### Core components + The Doter consists of several core components： Account part: with the help of Doter, users can create account, retrieve account, and backup account conviently. Through these accounts, users can complete a series of core interactions with the Polkadot ecosystem. @@ -31,47 +32,53 @@ Query part: Doter provides many portals to facilitate users to query some common Setting part: with the help of this part, users can easily set the extension to make it closer to their habits. A lot of common community public packages are used to ensure the consistency and correctness of business logic in Doter, such as @polkadot/api, @polkadot/keyring, @polkadot/util etc. In the specific development process, we use a lot of encapsulated public packages based on web technology, so as to ensure a good experience in the browser. + #### UI prototype -* Create wallet +- Create wallet ![img](https://uploader.shimo.im/f/AvN1H55TIy37Mng1.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Import wallet +- Import wallet ![img](https://uploader.shimo.im/f/L2KdTUpEdaLUZFV7.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Transfer and receive +- Transfer and receive ![img](https://uploader.shimo.im/f/ls2kbqxw9OkhNEbz.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Settings +- Settings ![img](https://uploader.shimo.im/f/P23QRARBLwBGQSS0.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Manage +- Manage ![img](https://uploader.shimo.im/f/1YOSQkFmPIg8tUGl.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Transaction records, etc. +- Transaction records, etc. ![img](https://uploader.shimo.im/f/q1gFLzRqrYdAvnxO.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Governance +- Governance ![img](https://uploader.shimo.im/f/ppL6L43PPaQuic1g.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Signature and injection +- Signature and injection ![img](https://uploader.shimo.im/f/lvYJi1DQ4ASFCcIF.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -* Staking +- Staking ![img](https://uploader.shimo.im/f/MDALPQL6MM0DjPcg.png!thumbnail?accessToken=eyJhbGciOiJIUzI1NiIsImtpZCI6ImRlZmF1bHQiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjE2MTc4NDMwNzMsImciOiJtNGtNTFpweGJuczYxQnFEIiwiaWF0IjoxNjE3ODQxMjczLCJ1Ijo1MjU3NjQ4MX0.-mNzWD92LrbP3ECC42XhCJrIxQqDVhepXo_KK3yXEgQ) -### Ecosystem Fit +### Ecosystem Fit #### Competitive product analysis + Polkadot's browser extension wallet, the currently known competitor is Enzyme. -* From the perspective of feature richness, the functional modules achieved by Doter's first milestone have exceeded Enzyme (Recently, we have completed the first milestone), and more functional modules that will serve the Polkadot ecology will be implemented in the plan. -* From the perspective of UI experience, Doter is a real user-centric wallet. A clear and concise UI experience is more attractive to users, and Doter has achieved Chinese and English language switching, which has a wider potential user group. -* From the perspective of github maintenance frequency, Enzyme has not been maintained for more than 1 year. In contrast, Doter has a clear development roadmap and the code base is constantly updated. + +- From the perspective of feature richness, the functional modules achieved by Doter's first milestone have exceeded Enzyme (Recently, we have completed the first milestone), and more functional modules that will serve the Polkadot ecology will be implemented in the plan. +- From the perspective of UI experience, Doter is a real user-centric wallet. A clear and concise UI experience is more attractive to users, and Doter has achieved Chinese and English language switching, which has a wider potential user group. +- From the perspective of github maintenance frequency, Enzyme has not been maintained for more than 1 year. In contrast, Doter has a clear development roadmap and the code base is constantly updated. #### The difference between Doter and polkadot.js extension -Polkadot.js extension is an official account management tool, Compared with polkadot.js extension, Doter's positioning is not only an account management tool. -Doter will also implements a series of common functions in Polkadot ecology, such as Transfer and receive, query transaction records, wallet management, easy-to-operate on-chain governance modules, etc. This means that doter can not only interact well with other dapps, but also independently complete the functions mentioned above, providing users with a one-stop experience, which polkadot.js extension does not have. + +Polkadot.js extension is an official account management tool, Compared with polkadot.js extension, Doter's positioning is not only an account management tool. +Doter will also implements a series of common functions in Polkadot ecology, such as Transfer and receive, query transaction records, wallet management, easy-to-operate on-chain governance modules, etc. This means that doter can not only interact well with other dapps, but also independently complete the functions mentioned above, providing users with a one-stop experience, which polkadot.js extension does not have. In addition, Doter will also provide a completely user-centric UI experience to make it easier for users to participate in the Polkadot ecosystem. #### Product direction and advantages -Analogous to MetaMask, in the current industry environment, browser extension wallets are more convenient to interact with DApp than mobile wallets. Doter is positioned as a browser extension wallet and has a first-mover advantage in the product direction. + +Analogous to MetaMask, in the current industry environment, browser extension wallets are more convenient to interact with DApp than mobile wallets. Doter is positioned as a browser extension wallet and has a first-mover advantage in the product direction. At the same time, most of the current mobile wallets connected to Polkadot are not dedicated to the Polkadot ecosystem, and there is no in-depth development based on Polkadot. Doter focuses on the Polkadot ecosystem and enables more users to participate in the Polkadot ecosystem through customized and truly friendly interactive experience. #### How to maintain the wallet + In the near future, Our team will have someone in charge of maintaining the Doter, Update at least once a month to fix bugs or improve the experience，to making Doter as close as possible to mature browser extension in other ecosystems(such as Ethereum) Simultaneously, we will build our own community as soon as possible. We believe that a solid community is the foundation for Doter to seize the market, Through word of mouth from seed users, we will accumulate the first batch of users. After completing all the milestones, we will place advertisements in a number of blockchain media, and rapidly expand the number of users through advertising. Secondly, we will embed a frequently used DApp in the wallet and cultivate user habits through this, so that Doter will gradually become the portal of the Polkadot ecosystem. @@ -81,36 +88,45 @@ In summary, we have appropriate market timing, clear product direction, reliable ## Team ### Team members -* Guan Yu -* Gao Jianli + +- Guan Yu + +- Gao Jianli ### Contact -* **Contact Name:** Gao Jianli -* **Contact Email:** dianluyuanli@foxmail.com -* **Website:** Doter is currently maintained on [Github](https://github.com/ChainBridgeNetworkTeam/Doter), no website has been created yet -### Legal Structure +- **Contact Name:** Gao Jianli + +- **Contact Email:** dianluyuanli@foxmail.com +- **Website:** Doter is currently maintained on [Github](https://github.com/ChainBridgeNetworkTeam/Doter), no website has been created yet + +### Legal Structure + Doter is maintained by the [ChainBridgeNetworkTeam](https://github.com/ChainBridgeNetworkTeam), and no company entity has been created yet, The following is our communication information. -* Mailing address: 504, Building 16, Lane 270, Maotai Road, Changning District, Shanghai, China -* E-mail：dianluyuanli@foxmail.com, muskshi@foxmail.com -* Twitter：ChainBridgeNet1 -* WeChat Official Accounts：ChainBridgeNetwork + +- Mailing address: 504, Building 16, Lane 270, Maotai Road, Changning District, Shanghai, China +- E-mail：dianluyuanli@foxmail.com, muskshi@foxmail.com +- Twitter：ChainBridgeNet1 +- WeChat Official Accounts：ChainBridgeNetwork ### Team's experience -* Guan Yu + +- Guan Yu He participated in Polkadot's official crowdfunding campaign in 2017 and has continued to be active in the Polkadot community ever since. From July 2018 to the present, he has been serving as a product manager for Pinduoduo Inc.(listed on NASDAQ), responsible for building core business modules such as CPS. He has 3 years of experience in large-scale Internet companies, is familiar with the development and maintenance of large-scale products, and is good at leading the business from 0 to 1 and achieving rapid growth. -* Gao Jianli +- Gao Jianli He joined Pinduoduo Inc.（listed on NASDAQ）in 2018 and became a full-time front-end development engineer. Responsible for the maintenance of the website promotion page, maintenance and development of the weChat applet architecture Project deployment and launch, development of productivity tools. He has three years of development experience, is familiar with project deployment and front-end technology stack, and is keen on Polkadot ecological technology trends. Personal Code Repos：https://github.com/dianluyuanli-wp ### Team Code Repos -* https://github.com/ChainBridgeNetworkTeam/Doter + +- https://github.com/ChainBridgeNetworkTeam/Doter ### Team LinkedIn Profiles + Guan Yu：https://www.linkedin.com/in/yu-guan-482624155/ Gao Jianli：https://www.linkedin.com/in/jianli-gao-6785a1140/ @@ -119,26 +135,30 @@ Gao Jianli：https://www.linkedin.com/in/jianli-gao-6785a1140/ **In particular, we have completed the basic module of the Doter wallet, and the extension program has been put on the Google extension market. You can already [install](https://chrome.google.com/webstore/detail/doter/abamjefkidngfegdjbmffdmbgjgpaobf) and use Doter.** The following is a list of functions that have been implemented -* Create and import wallets on Polkadot -* Transfer and receive on Polkadot -* Backup wallet on Polkadot -* Query transaction records on Polkadot -* Referendum on the chain on Polkadot -* Switch multiple wallets on Polkadot -* Manage address book on Polkadot -* Switch language on Polkadot + +- Create and import wallets on Polkadot +- Transfer and receive on Polkadot +- Backup wallet on Polkadot +- Query transaction records on Polkadot +- Referendum on the chain on Polkadot +- Switch multiple wallets on Polkadot +- Manage address book on Polkadot +- Switch language on Polkadot ### Overview -* Total Estimated Duration: 2 month -* Full-time equivalent (FTE): 34 -* Total Costs: $16,150 + +- Total Estimated Duration: 2 month + +- Full-time equivalent (FTE): 34 +- Total Costs: $16,150 ### Milestone + #### M1: Injection and signature -* Estimated Duration: 1 month -* FTE: 14 -* Costs: $6,650（2 contributors * 7 FTE * $475/FTE） +- Estimated Duration: 1 month +- FTE: 14 +- Costs: $6,650（2 contributors *7 FTE* $475/FTE） | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -146,14 +166,14 @@ The following is a list of functions that have been implemented | 0b. | Description | We will implement wallet injection and transaction signature on Polkadot, and optimize the UI experience of existing funcctions. | | 0c. | Delivery time | Mid May | | 0d. | How to verify | It is expected that in Mid May, you can install the latest version of Doter in the Google Extended Market and verify the functional modules promised in the milestone. In addition, you can also verify through integration tests, We will provide yarn commond for anyone who want to run the unit test scripts and check the results. | -| 1. | Core component | * Wallet injection on Polkadot
          * Transaction signature on Polkadot
          * Optimize account creation, transfer, account management and other functions to improve user experience +| 1. | Core component | * Wallet injection on Polkadot
          * Transaction signature on Polkadot
          * Optimize account creation, transfer, account management and other functions to improve user experience | #### M2: Support kusama network -* Estimated Duration: 1 month -* FTE: 20 -* Costs: $9,500（2 contributors * 10 FTE * $475/FTE） +- Estimated Duration: 1 month +- FTE: 20 +- Costs: $9,500（2 contributors *10 FTE* $475/FTE） | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -161,10 +181,11 @@ The following is a list of functions that have been implemented | 0b. | Description | We will support all functional modules that have been implemented on Polkadot. | | 0c. | Delivery time | Mid June | | 0d. | How to verify | It is expected that in mid June, you can install the latest version of Doter in the Google Extended Market and verify the functional modules promised in the milestone. In addition, you can also verify through integration tests, We will provide yarn commond for anyone who want to run the unit test scripts and check the results. | -| 1. | Core component | * Create and import wallets on Kusama
          * Transfer and receive on Kusama
          * Backup wallet on Kusama
          * Query transaction records on Kusama
          * Referendum on the chain on Kusama
          * Switch multiple wallets on Kusama
          * Manage address book on Kusama
          * Switch language on Kusama
          * wallet injection and signature on Kusama +| 1. | Core component | * Create and import wallets on Kusama
          * Transfer and receive on Kusama
          * Backup wallet on Kusama
          * Query transaction records on Kusama
          * Referendum on the chain on Kusama
          * Switch multiple wallets on Kusama
          * Manage address book on Kusama
          * Switch language on Kusama
          * wallet injection and signature on Kusama | ## Community engagement + This is a tutorial posted on medium：https://chainbridgenetwork.medium.com/polkadots-browser-extension-wallet-doter-ac8cd91a5bf3 ## Future Plans @@ -174,6 +195,7 @@ Doter’s development team is ChainBridgeNetworkTeam. As the name suggests, our Doter is our first product. We believe that with the launch of the parachain, Doter will act as an important interaction bridge in the Polkadot ecosystem. After completing the development of 2 milestones, we will design Doter version 2.0. In version 2.0, users can easily manage private digital assets without memorizing mnemonic words. This will be achieved through an innovative technology. We believe in version 2.0 Doter will greatly reduce the threshold for users to use wallets, making Doter a real bridge between Polkadot and ordinary users. ## Additional Information + ChainBridgeNetworkTeam has just been established for two months, but we have completed the basic module of Doter, and have designed the other two milestones. In the next two months, we will deliver all pre-designed functional modules. So far, we have developed at our own expense, but in order to have sufficient funds to support the realization of our long-term vision, we will try to obtain the support of investment institutions. diff --git a/applications/Dotflow.md b/applications/Dotflow.md new file mode 100644 index 00000000000..911378d0ef7 --- /dev/null +++ b/applications/Dotflow.md @@ -0,0 +1,201 @@ +# Dotflow + +- **Team Name:** Sergej Sakac & Oliver Lim +- **Payment Address:** 0x1e86CD18E4443B5f57b0133077954Cd84896964d (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +#### Problem +We can most certainly agree that the future is multi-chain. As such, it is not uncommon for users to hold multiple accounts across various chains for reasons such as distinct address formats and security benefits. However, this practice presents a challenge in managing multiple addresses. Adding to the complexity is the need to verify the address of the intended recipient, as it may have changed over time. + +In summary, there are two key challenges to address: the management of multiple addresses and making sure the addresses of the recepients did not change in the meantime. + +To mitigate these challenges, we aim to simplify the user experience by abstracting away the complexity of address management. + +### Project Details + +Our project will comprise two smart contracts coded in ink!, and a React.js-based user interface. + +One of the ink! contracts will store the user's address-related data in an entity called `Identity`. Each user will have their own `Identity`, containing their addresses across different chains. The Identity creators will be responsible for updating their addresses if any changes occur. Every Identity will be assigned a unique `IdentityNo`, which will serve a crucial purpose in the address book contract and UI. + +Additionally, this contract will feature a function that, based on input arguments, will return the appropriate destination address for token transfers. This function will mainly be used by the user interface. + +The second contract will be an address book that enables users to store the `IdentityNos` of the people they are most frequently engaged with. Each user will have the option to create their own address book, where they can add a nickname to each identity to differentiate them easily. Each address book will be attached to a wallet so that when a user logs in with his wallet the UI and provides the `IdentityKey` the frontend will automatically be able to display the address book to the user. + +The UI will serve the purpose of interacting with both smart contracts. Users will be able to create an identity and customize the addresses of their identity. Using the UI users will also be able to create their address book and customize it. The most important functionality the UI will provide will be the routing. +When a user wants to transfer some tokens to an identity the user will only have to worry about the token, origin and destination chain, and the identity they want to send the tokens to. Based on all of this the UI will query the identity contract and based on that create a transaction that will route the tokens to the proper address. + +In case the origin and destination chain are not the same, the UI will create an XCM message that will route the tokens to the proper blockchain. For the XCM transaction to work there has to be an existing XCM channel between the two blockchains. + +### Privacy +Most of us don't want to share all of our addresses with the rest of the world. For that reason, we are including some privacy features that will keep all our addresses private. +All of the addresses in the identity smart contract will be encrypted with a secret key. + +Users will have multiple addresses each attached to a certain blockchain. AES 128-bit ciphers will be generated by the UI per each blockchain. These ciphers will only change if the user changes them when updating an address, otherwise, they will always be the same for the associated blockchain. +Ciphers will be created when creating an identity or when adding a new blockchain address to the identity. These ciphers will be stored in a structured format so that the frontend code can associate each cipher with a blockchain. Ciphers will be stored locally in the following format: +``` +-- We will call this data the 'Identity Key' -- +blockchain_name_1:cipher_1;blockchain_name_2:cipher_2;...and so on +``` +Each address will be encrypted with the associated cipher before it gets stored in the identity contract. This will ensure that no one has access to an identity's addresses simply by reading the contract's state. + +To share an identity with someone the `Identity Key` will also be needed to be sent together with the `IdentityNo`. In case an identity doesn't want to expose all of their addresses to someone else, but only some of them, it is possible to send part of the `Identity Key` that contains the ciphers for the blockchain addresses he wants to share. +Of course, the user won't need to do this task manually, the UI will make this task very simple. The following section will show how this will work from the user's perspective. + +In case we update some of our addresses but we want to restrict access to the users that previously were granted access to that address there will be an option to regenerate the cipher. This way everyone that had access to the old address won't have access to the new one. + +### UI Design +The UI will consist of three main parts: + +- My Identity page +- Transfer page +- Address book page + +#### My Identity page +[![1-1-dashboard-2.png](https://i.postimg.cc/nLt38NpZ/1-1-dashboard-2.png)](https://postimg.cc/dh42rHhS) + +The user will be able to create his own identity and provide the addresses he owns on to his identity. + +![Add Address](https://i.postimg.cc/jdKdPQS5/1-1-create-identity.png) + +In case some of the addresses the user owns change over time he will be able to edit them. +Also, we can select the option to regenerate the cipher so that people that had access to the old address won't be able to access the new one. + +[![1-1-create-identity-4.png](https://i.postimg.cc/509Z5LX0/1-1-create-identity-4.png)](https://postimg.cc/jW9gtWQ0) + +When sharing their identity users will also be able to select which addresses will be available for the person they are sending their identity to. The user will have to copy his `identityNo` but also the `identityKey` which specifies which addresses are accessible for the user that receives this key. + +[![1-1-create-identity-2.png](https://i.postimg.cc/BnhvGMML/1-1-create-identity-2.png)](https://postimg.cc/fV9scj4D) + +#### Transfer page +[![2-1-transfer-1.png](https://i.postimg.cc/Cx9ZCHpB/2-1-transfer-1.png)](https://postimg.cc/75MYwz6w) + +Ther user will be able to transfer tokens to an identity by specifying the origin chain, destionation chain, and the receiver's `identityNo`. + +#### Address Book page +![Address book page](https://i.postimg.cc/QtXyT9kK/3-1-Address-book.png) + +The user will be able to add identities to his own address book. The identities will be added by providing the `identityNo` and some nickname for the identity. + Also by clicking on the transfer icon on one of the identities the user will be redirected to the transfer page where the `identityNo` will be automatically filled out. + +[![3-1-Address-book-3.png](https://i.postimg.cc/xT5snzHN/3-1-Address-book-3.png)](https://postimg.cc/PPLbMNSd) + +When adding an Identity to an address book the user will also be required to provide the Identity Key which will be used for decrypting the identity's addresses when sending tokens. + +### Ecosystem Fit + +This project fits perfectly with the Polkadot ecosystem because it has everything we need to make it work. Polkadot is a multi-chain network, so a lot of users have different addresses on different chains for the same reasons we mentioned earlier. That's why the problems we talked about are important in this ecosystem. + +XCM is going to be a core component of our project since it'll help us transfer tokens between the parachains and the relay chain. + +#### Target Audience +Our target audience is people who deal with sending assets frequently over the Polkadot network. + +## Team :busts_in_silhouette: + +### Team members + +- Sergej Sakac [Szegoo](https://github.com/Szegoo) +- Oliver Lim [cuteolaf](https://github.com/cuteolaf) + +### Contact + +- **Contact Name:** Sergej Sakac +- **Contact Email:** sakacszergej@gmail.com +- **Website:** https://github.com/Szegoo + +### Legal Structure +- **Registered Address:** Kanalska 7 Novi Sad Serbia +- **Registered Legal Entity:** MASTER UNION LLC. + +### Team's experience + +#### [Sergej Sakac](https://github.com/Szegoo) +- More than three years of programming experience +- Active contributor to [Substrate](https://github.com/paritytech/substrate/pulls?q=is%3Apr+author%3ASzegoo) +- Member of the [fellowship](https://github.com/polkadot-fellows/seeding/pull/36) +- Contributor to [rmrk-pallets](https://github.com/rmrk-team/rmrk-substrate/pulls?q=is%3Apr+is%3Aclosed+author%3ASzegoo) + +#### [Oliver Lim](https://github.com/cuteolaf) +- Full stack blockchain developer with 5+ years of experience +- Quick learner and active contributor to open source projects + - [Fair Squares](https://github.com/fair-squares/fair-squares) + - [Imbue Network](https://github.com/imbuenetwork) + - [Anagolay Network](https://gitlab.com/anagolay/anagolay) + - ... + +### Team Code Repos + +We will be working on two separate repos, one for the UI and the other for the ink! contracts. + +- https://github.com/TheDotflow/dotflow-ui +- https://github.com/TheDotflow/dotflow-ink + +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/Szegoo +- https://github.com/cuteolaf + +### Team LinkedIn Profiles (if available) + +- http://linkedin.com/in/sergej-sakac-334a47252 +- https://www.linkedin.com/in/oliver-lim-2215a8235/ + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2,5 months +- **Full-Time Equivalent (FTE):** 1.5 FTE +- **Total Costs:** 19,000 USD + +### Milestone 1 Example — Basic functionality + +- **Estimated duration:** 1 month +- **FTE:** 1,5 +- **Costs:** 8,000 + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | Ink! contracts and the UI code will be well documented and open for everybody to take a look. The UI will be simple and intuitive to use. | +| **0c.** | Testing and Testing Guide | The Identity ink! contract will be well tested with unit and integration tests. | +| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. | +| 1. | Identity Contract | We will write the code for the Identity contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Identity contract will provide a range of functions, including creating an identity, adding addresses that are mapped to specific blockchains, and updating these addresses as needed. The contract will automatically generate a unique identifier, referred to as `identityNo`, for each identity. To ensure maximum security, we will allow the identity creator to specify the accounts that are authorized to modify the identity's addresses. This will enable the creator to retain control of the identity even if they lose access to the account used to create it.| +| 2. | My Identity page | The My Identity page will be developed using React.js, providing users with a user-friendly interface to interact with the Identity contract. This will include the ability to create a new identity, add or remove addresses associated with an identity, and access and copy the unique `identityNo` to share with others. This UI will also generate the `Identity Key` for the user's identity and will update it every time he adds a new blockchain address. This `Identity Key` will be accessible for the identity creator when sharing his identity. The interface will be based on the mock design presented in the [UI design](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design) section. | + + +### Milestone 2 Example — Additional features + +- **Estimated Duration:** 1,5 month +- **FTE:** 1,5 +- **Costs:** 11,000 + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | The contract and the website code will be well documented and open for everybody to check. The UI will have a simple UI that will be intuitive to use. | +| **0c.** | Testing and Testing Guide | The Address Book ink! contract will be well tested with unit and integration tests. The functionality for generating XCM messages will very well tested to make sure the tokens are always transfered to the proper destination. | +| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milesone. | +| 0e. | Article | We will publish a Medium article that explains the details of our project. | +| 1. | Address Book | We will develop the code for the Address Book contract using ink! so that our contracts can be compiled to wasm and deployed to any blockchain that implements the contracts pallet. The Address Book will enable users to create an address book and populate it with the identities they interact with most frequently. The identities will be added via their identityNo since our main goal is abstracting away addresses from the users. When adding an identity to an address book the Identity Key will also be needed. The address book will be stored on chain but the `IdentityKey` will be stored in local storage. The application will expect the user to provide the `IdentityKey` when using the app from a different device for the first time. | +| 2. | Routing functionality. | The code responsible for routing tokens to the correct destination will be incorporated into the frontend code written in TypeScript. This code will incorporate the necessary logic for constructing XCM messages to route tokens to the appropriate address. In cases where the destination chain is the same as the origin, a simple transaction will be executed. Because of possible race conditions where the identity owner is trying to update an address on a parachain while another user is trying to send funds to that identity on that parachain we introduce additional checks on the frontend. Before sending a transaction that will transfer the funds, the frontend will check whether there are any pending transactions happening that would change the address on the chain the user is transferring funds to. In case there is a pending transaction the user will get a warning and will be advised to wait for a moment and try sending the transaction again. | +| 3. | Address Book page | We will write the code for the Address Book UI using React.js. The UI will be based on the provided mock design that we displayed above in the [UI design section](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design). The UI will make it possible for users to create an address book and add identities to it. | +| 4. | Transfer page | We will create a user interface using React.js that will enable users to send tokens to a designated `IdentityId`. This UI will abstract away the complexity of addresses and leverage the Routing functionality described in this table(Section 2) to handle token routing. The UI design will be based on the mock design presented in the [UI design](https://github.com/Szegoo/Grants-Program/edit/application/applications/Dotflow.md?pr=%2Fw3f%2FGrants-Program%2Fpull%2F1657#ui-design) section for optimal user experience. | + + +## Future Plans + +Our future plan is to expand our core functionality and add more features so that the tokens can be routed based on some different criteria. Some example of these ideas are: + +- Route tokens based on the amount, sender and/or the token itself +- Split the transferred amount to multiple addresses + +An exciting feature we would like to build in the future is enable token transfers between blockchains that are not part of the Polkadot network(e.g. Polkadot\<-\>Ethereum). + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** GitHub diff --git a/applications/Eiger_Storage_on_Polkadot_1.md b/applications/Eiger_Storage_on_Polkadot_1.md new file mode 100644 index 00000000000..e0467574a0c --- /dev/null +++ b/applications/Eiger_Storage_on_Polkadot_1.md @@ -0,0 +1,118 @@ +# Proposal: Storage solution on Polkadot + +- **Team Name:** Eiger +- **Payment Address:** Fiat 14.04.2023, 16:50 UTC+3 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + + +The main goal is to implement and maintain a Filecoin-like system parachain that uses DOT as the native token and is easily usable for all kinds of parachain projects in the ecosystem via XCM. + +### Project Details + +To accomplish this we are submitting this initial proposal to update our previous research and test how XCM could be used to allow the ecosystem to use this storage network. + +We are interested to build this because: +- Native storage in Polkadot payable in DOT is not currently available +- We have done the research 2 years ago. +- After talking to community members in Decoded 2023 we noticed there is demand for this kind of functionality. + +We will not be using Trusted Execution Environments or Enclaves in this solution. + +### + + +### Ecosystem Fit + +Currently a storage solution native to Polkadot is missing, by building a system parachain anyone in the ecosystem will be able to access storage thru XCM, pay in native DOT and build more complex applications withour relying on other networks. + + +## Team :busts_in_silhouette: + +Eiger - We help leading technology companies to scale and develop their core technologies to gain an edge by providing expert teams in the most critical areas of modern web3 development. + +Eiger is part of the [Equilibrium group](https://www.eqg.co/) which includes engineers from our sister company [Equilibrium Labs](https://equilibrium.co/). + +### Team members + +- **Tomek Piotrowski** ([Github](https://github.com/tomekpiotrowski), [Linkedin](https://www.linkedin.com/in/tomasz-piotrowski-17466b4/)) Software Engineer at Eiger, specializing in Rust-based applications. With a strong background in software development, he has spent recent years focusing on the Rust programming language. At Eiger, Tomasz actively contributes to the advancement of Rust-based blockchains and their ecosystems. +- **Mark Henderson** ([GitHub](https://github.com/aphelionz), [Twitter](http://twitter.com/aphelionz)) is the VP of Engineering at Equilibrium. He has led the team starting with the original Rust IPFS implementation in late 2019, through engagements with many of the largest names in Web3, and is part of the team that did [the original research](https://github.com/common-good-storage/report/blob/master/src/first.md) 2 years ago. Core contributor to OrbitDB, Rust IPFS, and Ziggurat. +- **Piotr Olszewski** ([Github](https://github.com/asmie), [LinkedIn](https://www.linkedin.com/in/piotr-olszewski-8a239939/)) & **Karlo Mardesic** ([Github](https://github.com/Rqnsom), [LinkedIn](https://www.linkedin.com/in/karlo-mardesic/)) - currently working on MoveVM pallet, they will contribute with their Polkadot and Substrate knowledge and join the next stage of this project, implementation. + +### Contact + +- **Contact Name:** Daren Tuzi +- **Contact Email:** daren@eiger.co (Founder & CEO of Eiger) +- **Website:** [Eiger.co](https://www.eiger.co/) + +### Legal Structure + +- **Registered Address:** Linnankatu 3 A 24, 20100 Turku, Finland +- **Registered Legal Entity:** Eiger Oy + +### Team's experience + +- [We researched this very topic 2 years ago](https://github.com/common-good-storage/report/blob/master/src/first.md) +- [We are the main contributors to implementing IPFS in Rust](https://github.com/rs-ipfs/rust-ipfs) +- We are building a MoveVM pallet for Polkadot (we will deliver Milestone 1 next week) + +Our clients include: Starknet, Aleo, Forte, Zcash, Fireblocks, Ripple, Algorand, Solana, Flow, Elusiv, Celestia, Stellar and more. + +### Team Code Repos + +- Contributions to SnarkOS for Aleo. https://github.com/AleoHQ/snarkOS +- OrbitDB is a distributed, p2p, serverless database. https://github.com/orbitdb/orbit-db +- The rust implementation of IPFS. https://github.com/rs-ipfs/rust-ipfs +- The main implementation of Interledger in Rust. https://github.com/interledger/interledger-rs +- Ziggurat - A Network protocol testing framework for ZCash, XRP, and Algorand. Notably, critical network vulnerabilities were found and reported to the core teams. https://github.com/runziggurat +- Pathfinder, the full node implementation of Starknet https://github.com/eqlabs/pathfinder +- Zcash uniffi https://github.com/eigerco/uniffi-zcash-lib + + +## Development Status :open_book: + +The goal of this proposal is to update the work we have done in the past to account for what has changed in the past 2 years in the Polkadot ecosystem and the advancements made in storage solutions like Filecoin. + +In addition to this research and updating the code, we will also test how XCM could be used by anyone in the ecosystem to interact with this storage. + +## Development Roadmap :nut_and_bolt: + +### Update research, update code and test XCM + +- **Total Estimated Duration:** 1 month +- **Full-Time Equivalent (FTE):** 1.5 +- **Total Costs:** 30,000 USD + + +Two engineers will work together and in parallel to deliver these 3 subcomponents: + +1. Update the research done previously to reflect latest tech changes in Polkadot and Substrate. We want to figure out what it would take to implement a whole storage solution as a parachain without depending on 3rd part chains and evaluate what components need to be written from scratch and what can be reused. +2. Update the [code delivered in CGS](https://github.com/common-good-storage/parachain) or start fresh, whichever makes most sense. The scope of this is to deliver scafolding/template repository with boilerplace and dummy funcitonality. On top of this we can then test the milesone #3 below. +3. Research and test how XCM can be used. Using the scafolding code from #2 we can test how XCM can be used to access the storage from a different parachain. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | Copyright and Licenses | Apache 2.0 and MIT | +| **0b.** | Documentation/Tutorial | We will provide both inline documentation of the POC code and a basic tutorial that explains how a user can run the same test. | +| **0c.** | Methodology | Detailed explanation of how the results were achieved and how to reproduce/verify the results. | +| **0d.** | Infrastructure | We will provide the list of all requirements that can be used to verify the code deliverable with this milestone. This is related to deliverable 0b. Documentation and 0g. Docker | +| **0e.** | Article | Content: Updated research doc detailing our findings, how the tech has changed and how the solution will look like. | +| **0f.** | Testing and Testing Guide | We will deliver code that tests how XCM might be used to access this storage parachains. | +| **0g.** | Docker | Where relevant. we will provide a Dockerfile(s) that can be used to run and test the MVP and the XCM test. | +| **1.** | Updated CGS code | We will deliver a repositiory with the update MVP code | + + + + +## Future Plans + +This initial grant will produce a game plan on how exactly this storage network will work. Using this knowledge we will submit another future proposal to build this solution. Once this storage solution has been built, it will be voted on by a governance vote. If successful then this system parachain will be available to be used by anyone in the ecosystem and payable in native DOT. + + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** We are working on MoveVM pallet grant which asnwers the original RFP from the foundation so we were familiar with the ecosystem. diff --git a/applications/ElizaPluginPolkadot.md b/applications/ElizaPluginPolkadot.md new file mode 100644 index 00000000000..8d90178d317 --- /dev/null +++ b/applications/ElizaPluginPolkadot.md @@ -0,0 +1,179 @@ +# Polkadot ElizaOS Plugin + +- **Team Name:** Esscrypt Ltd. +- **Payment Details:** + - **DOT**: 15JRT5GjLAZkuvmpwmjCUp1RRLr7Y6Gnusz37ia37h2Xn5Rz + - **Payment**: 15JRT5GjLAZkuvmpwmjCUp1RRLr7Y6Gnusz37ia37h2Xn5Rz (USDC) +- **[Level](https://grants.web3.foundation/docs/Introduction/levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +**Empowering decentralized AI with Polkadot on-chain integration.** + The Polkadot ElizaOS Plugin is an open-source integration module designed to connect ElizaOS—a decentralized AI operating system—with the Polkadot ecosystem. The plugin provides a set of actions and providers for AI agents to access real-time on-chain data, query governance information, and interact with common parachain smart contracts, opening up the possibility for agentic interactions on Polkadot networks. + Our plugin leverages the polkadot-js API for data feeds, utilizes Polkadot’s XCMP for cross-chain communication, and provides standardized interfaces for smart contract interactions on parachains. This tight integration enables seamless interaction between AI systems and the Polkadot network. + Our team is driven by a passion for decentralized innovation. With extensive experience in blockchain integration and decentralized AI, we aim to reduce technical complexity and accelerate innovation by creating a standardized tool that benefits developers and researchers in the Polkadot ecosystem. + +### Project Details + +- **UI/UX Designs:** + Initial mockups for administrative dashboards and API usage examples are available as part of our internal design documents. +- **Data Models / API Specifications:** + The plugin API will cover endpoints for: + - Retrieving on-chain data (balances, block information, event logs). + - Querying governance proposals and voting results. + - Interacting with parachain smart contracts. + + Detailed API specifications and data models will be documented using OpenAPI standards. +- **Technology Stack:** + - **Integration Layer** TypeScript with polkadot-js. + - **Framework:** ElizaOS Monorepo set up with all necessary prerequisites for a fully functional local testing environment. + - **Testing & Documentation:** Comprehensive unit tests (>95%); detailed inline documentation and user guides. Screenshots of end-to-end deep testing using a test AI Agent +- **Core Documentation:** + We will provide full technical documentation including architecture diagrams, integration guides, and API tutorials. +- **Prior Work:** + Our team has successfully delivered integration plugins for other blockchain ecosystems, such as the [ElizaOS TON Plugin](https://github.com/elizaos-plugins/plugin-ton/pull/18), which demonstrates our ability to build robust, community-driven, open-source projects. +- **Scope Limitations:** + This project focuses solely on software integration for ElizaOS with Polkadot and does not include any token issuance, financial instruments, or business-oriented services. + +### Ecosystem Fit + +- **Ecosystem Positioning:** + The Polkadot ElizaOS Plugin acts as a bridge between decentralized AI and Polkadot’s data-rich environment, enabling developers to harness on-chain data, participate in governance, and utilize parachain smart contracts. +- **Target Audience:** + Developers and researchers building decentralized AI applications, dApp developers, and blockchain enthusiasts seeking simplified integration with Polkadot. +- **Needs Addressed:** + It streamlines agentic access to on-chain data and governance information, reducing the complexity of integrating blockchain functionalities into AI systems. +- **Need Identification:** + Our requirements are based on extensive community discussions and experience from other ecosystems. +- **Competitive Landscape:** + While several projects exist for blockchain integrations, none specifically target the intersection of ElizaOS as one of the most widely used Agentic frameworks and Polkadot’s unique capabilities. Our plugin’s focus distinguishes it from existing solutions. +- **Related Projects:** + Similar integrations exist in the Ethereum ecosystem, but our solution is tailored for Polkadot’s architecture and its cross-chain interoperability features. + +## Team :busts_in_silhouette: + +### Team members + +- **Mihail Kirov:** + Lead Developer with 5+ years of experience in distributed systems and blockchain integration. Specializes in connecting AI systems with decentralized networks and has a strong track record in open-source contributions. + Mentored at the [Polkadot Prodigy](https://www.linkedin.com/posts/polkadotprodigy_lets-welcome-mihail-kirov-who-is-joining-activity-7191345617330192384-DJbv?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAAC27-YYBCPf5vbQMBXvlthYYXnOflSOp-9A) Hackathon + [GitHub: mikirov](https://github.com/mikirov) | [LinkedIn](https://www.linkedin.com/in/mihail-kirov/) + +- **Tyler Ellis McWilliams:** + Blockchain Developer with 5+ years of experience in decentralized applications, tokenomics, and smart contracts. Expert in multi-language development and AI integration, with extensive contributions to open-source projects. + [GitHub: tylermcwilliams](https://github.com/tylermcwilliams) | [LinkedIn](https://www.linkedin.com/in/tyler-mcwilliams-85256a117) + + +### Contact + +- **Contact Name:** Mihail Kirov +- **Contact Email:** me@mikirov.xyz +- **Website:** [esscrypt.com](https://esscrypt.com/) + +### Legal Structure + +- **Registered Address:** Mladost 3, bl. 313, ent. 3, fl. 10, ap. 66, 1799, Sofia, Bulgaria. +- **Registered Legal Entity:** Escrypt Ltd. + +### Team's experience + +### Team Code Repos + +- [Mihail Kirov](https://github.com/mikirov) +- [Tyler Ellis McWilliams](https://github.com/tylermcwilliams) + +### Team LinkedIn Profiles + +- [Mihail Kirov](https://www.linkedin.com/in/mihail-kirov/) +- [Tyler Ellis McWilliams](https://www.linkedin.com/in/tyler-mcwilliams-85256a117) + +## Development Status :open_book: + +We have conducted preliminary research and have established a solid architectural design for the Polkadot ElizaOS Plugin. +Initial prototypes and integration experiments with the polkadot-js API have been performed, +and design documents outlining core functionalities, data models, and API specifications are available. +Our prior work on similar projects (TON, IOTA and Ocean integrations) further validates our technical approach. +Detailed documentation and research findings will be maintained in our repositories and published blog posts. + +## Development Roadmap :nut_and_bolt: +### Overview + +- **Total Estimated Duration:** 120 person-days +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 20,000 USD +- **DOT %:** 50% of total costs + +### Milestone 1 — Wallet and On-Chain Observability + +- **Estimated Duration:** 1 month +- **FTE:** 2FTE, the listed members would contribute to different deliverables based on their skill-set. +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| ------ | --------------------------------- | ----------------------------------------------------------------------------------------------------------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | Inline code documentation and a tutorial on how to set up the plugin and perform test queries using polkadot-js | +| **0c.** | Testing and Testing Guide | Comprehensive unit tests covering core functions with instructions on running these tests | +| 1. | Wallet Integration | Create actions to create a wallet, eject wallet, utilizing end-to-end encryption of the private key | +| 2. | On-Chain Data Feed Module | Create actions to retrieve on-chain data (balances, block numbers, event logs) using polkadot-js API | +| 3. | Governance Query Module | Develop actions to query and parse governance proposals, referenda, and voting results from Polkadot | + +**Plugin Actions:** +- **Polkadot Wallet Creation:** + - Allows the user to create a new wallet, with both a user-provided secret and agent-generated one. +- **Polkadot Wallet Eject:** + - Allows the user to export their wallet using their passkey. +- **Retrieve On-Chain Data:** + - Action to fetch and filter on-chain data such as account balances, block information, and event logs. + - Retrieves live data from Polkadot nodes via the polkadot-js API. +- **View Governance Data:** + - Action to display current governance proposals and voting results from Polkadot’s governance modules. + +**Providers:** +- **Polkadot Wallet Provider:** + - Authenticate users by signing messages or transactions. Requires a created wallet, or secrets set up in env. +- **Polkadot Data Provider:** + - Integrates with the polkadot-js API to fetch on-chain data and governance information. + - Manages API authentication, connection to Polkadot nodes, and error handling. + +**Developer Tasks:** +- Establish the plugin framework within ElizaOS. +- Set up integration and unit tests targeting ≥95% coverage. +- Define common interfaces for future actions and providers. + +### Milestone 2 — Asset Hub Subsidized Transactions and Cross-Parachain Transfers + +- **Estimated Duration:** 1 month +- **FTE:** 2FTE, the listed members would contribute to different deliverables based on their skill-set. +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| ------ | --------------------------------- | ----------------------------------------------------------------------------------------------------------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | Detailed documentation of governance query actions and smart contract interaction modules | +| **0c.** | Testing and Testing Guide | Unit tests covering governance and contract interactions with testing instructions | +| 4. | Transfers & Transactions | Execute token transfers between accounts, multisigs, or across parachains (XCMP transfers). +| 5. | Subsidized Transactions | Subsidized payment of transaction fees using asset hub's sufficient assets. | +| 6. | Official ElizaOS Repository Integration | Submit a pull request to the official ElizaOS plugin repository and ensure successful merge. This ensures the plugin becomes an official part of the ElizaOS ecosystem and is accessible to all ElizaOS users. | + +## Future Plans + +- **Long-Term Maintenance:** + We plan to sustain the project through continuous community contributions and by exploring partnerships that provide service-based revenue streams. Our open-source approach ensures that the community can extend and improve the plugin over time. +- **Short-Term Enhancements:** + We will introduce advanced analytics tools for real-time monitoring, support additional parachain networks, and implement custom runtime modules based on community feedback. +- **Long-Term Vision:** + Our roadmap includes the development of easy-to-extend and intuitive interfaces, allowing contributors to easily extend and build on top of the plugin. +- **PVM readiness** + One of our main goals will be to develop the current plugin with extensibility and forwards-compatibility in mind, defining common interfaces in such a way that a future AssetHub integration will be easier + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +- Research over missing ElizaOS ecosystems. +- **Additional Work:** + Our team has previously delivered successful integrations for the TON network. This is our first grant application for a Polkadot-specific project, marking our commitment to advancing decentralized AI technologies within the Polkadot ecosystem. +- **Previous Grants:** + None. diff --git a/applications/EverlastingCash.md b/applications/EverlastingCash.md index f077809f462..c9b62b1c7cc 100644 --- a/applications/EverlastingCash.md +++ b/applications/EverlastingCash.md @@ -1,57 +1,62 @@ -# Open Grant Proposal +# Everlasting Cash -* **Project Name:** Everlasting Cash -* **Team Name:** Cycan Technologies -* **Payment Address:** ETH address: 0x722043b40dEb4656a103aF03Fd8E781d0146d3F6 -* **Status:**: Terminated +- **Team Name:** Cycan Technologies +- **Payment Address:** ETH address: 0x722043b40dEb4656a103aF03Fd8E781d0146d3F6 +- **Status:**: Terminated -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview - * While the incumbent stablecoins in the market have served the purpose of stabilizing the prices of cryptocurrencies, there are obvious limitations. Fiat-backed stablecoins such as USDT are not decentralized with the risk of being compromised by the central entity; while crypto-backed stablecoins are more vulnerable to price instability, since they are pegged to other cryptocurrencies. The risk of a possible crash for non-collateralized stablecoins is relatively high, since they lack collateral to liquidate the coin back into, while commodity-backed stablecoins might have liquidity problems as physical assets are not so easily liquidated. - * Everlasting Cash is a new kind of stablecoin which solves these issues with a truly decentralized, anti-inflation and stable product with reserves. - * Everlasting Cash a.k.a. ELC is a decentralized algorithmic stablecoin using Substrate with a unique reserve system, i.e. a hybrid of a crypto-collateralized and an algorithmic stablecoin mechanism, with the collateralized mechanism providing the underlying value guarantee, and the algorithmic mechanism incentivizing the participants on one hand, and hedging the downside risk when the demand for the stablecoin is insufficient on the other. - * ELC aims to provide users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. -### Project Details +- While the incumbent stablecoins in the market have served the purpose of stabilizing the prices of cryptocurrencies, there are obvious limitations. Fiat-backed stablecoins such as USDT are not decentralized with the risk of being compromised by the central entity; while crypto-backed stablecoins are more vulnerable to price instability, since they are pegged to other cryptocurrencies. The risk of a possible crash for non-collateralized stablecoins is relatively high, since they lack collateral to liquidate the coin back into, while commodity-backed stablecoins might have liquidity problems as physical assets are not so easily liquidated. +- Everlasting Cash is a new kind of stablecoin which solves these issues with a truly decentralized, anti-inflation and stable product with reserves. +- Everlasting Cash a.k.a. ELC is a decentralized algorithmic stablecoin using Substrate with a unique reserve system, i.e. a hybrid of a crypto-collateralized and an algorithmic stablecoin mechanism, with the collateralized mechanism providing the underlying value guarantee, and the algorithmic mechanism incentivizing the participants on one hand, and hedging the downside risk when the demand for the stablecoin is insufficient on the other. +- ELC aims to provide users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. + +### Project Details Everlasting Cash (ELC) contracts are written in Rust language and can be deployed to Polkadot/Kusama parachain (ink! pallet). #### Technical Design Overview - + #### Tokens + 1) Everlasting Parachain Token - ELP ELP is a native token of the Everlasting Parachain (a parachain on Kusama). Participants are able to send ELP to the ELC multifunction contract as reserve assets to exchange ELC: according to the different system liability ratios, the contract will return both ELC and rELP, or rELP only to participants (see “Reserve” paragraph below). 2) ELC Token -ELC token is the stablecoin within the ELC contract system, with the initial pegged rate of 1 USD value in the year of 2021. The pegged rate varies over time based on inflation and depends on whether its supply expands or shrinks based on the system LR. +ELC token is the stablecoin within the ELC contract system, with the initial pegged rate of 1 USD value in the year of 2021. The pegged rate varies over time based on inflation and depends on whether its supply expands or shrinks based on the system LR. 3) rELP Token rELP token is a risk asset in the ELC system (an equity in the system). Participants are able to add rELP liquidity to the multifunction pool, which could be realized by sending ELP to ELC contract. The system encourages user to do long-term liquidity mining so as to keep the reserve pool more stable with liquidity. #### Multifunction Pool + 1) Reserve Participants can send ELPs to the ELC system in exchange for both ELC and rELP, or rELP alone, depending on what the system liability ratios are. When the system LR is less than 30%, participants who send ELPs to the ELC system can obtain a certain amount of ELC and rELP minted and the LR of the system remains unchanged. When the system LR is higher than 30%, participants who send ELPs to the ELC system will only get rELP, and this can decrease LR. 2) Risk Reserve Fund -The risk reserve fund includes two assets (ELPs and ELCs). The purpose of the Risk Reserve Fund is to keep the ELC prices floating between 98% and 102% of the ELC aim price (ELCaim). For example, 1 million ELPs out of the overall 21 million of ELPs initial issuance are used as initial risk reserves. +The risk reserve fund includes two assets (ELPs and ELCs). The purpose of the Risk Reserve Fund is to keep the ELC prices floating between 98% and 102% of the ELC aim price (ELCaim). For example, 1 million ELPs out of the overall 21 million of ELPs initial issuance are used as initial risk reserves. Such risk reserve fund is used as follows: when ELP price is lower than 98% of ELCaim, the ELC system will swap ELP for ELC until all ELP in the pool are swapped into ELC to keep the price back to ELCaim. When ELP price is higher than 102% of ELCaim, the ELC system will swap ELC to ELP until all ELCs in the pool are swapped into ELP to keep the price back to ELCaim. 3) Liquidity Mining -Participants who have deposited ELPs to the reserve pool contract, can obtain rELP and use rELP to participate in the liquid mining. In order to maintain the size of reserves, participants are encouraged to do long-term liquidity mining. Participants who join liquidity mining will earn more tokens if they hold the tokens longer. +Participants who have deposited ELPs to the reserve pool contract, can obtain rELP and use rELP to participate in the liquid mining. In order to maintain the size of reserves, participants are encouraged to do long-term liquidity mining. Participants who join liquidity mining will earn more tokens if they hold the tokens longer. #### Inflation Governance + The generation time of ELP is 6 seconds per block. The ELP target price rises every 10,000 blocks in K, K is an anti-inflation factor. The inflation factor K can be adjusted through the ELP governance mechanism. rELP holders can vote for the adjustment of the anti-inflation factor K when the USD inflation goes into hyperinflation. #### Oracle -The oracle of reserve asset ELP and stablecoin ELC is implemented with Chainlink-Polkadot. We utilize Chainlink's decentralized Oracle network to quickly and securely connect end-to-end all the inputs and outputs of smart contracts to avoid pitfalls associated with deploying our own Oracle, such as long delays, additional charges, and even fatal security vulnerabilities. + +The oracle of reserve asset ELP and stablecoin ELC is implemented with Chainlink-Polkadot. We utilize Chainlink's decentralized Oracle network to quickly and securely connect end-to-end all the inputs and outputs of smart contracts to avoid pitfalls associated with deploying our own Oracle, such as long delays, additional charges, and even fatal security vulnerabilities. #### Contract + 1) ELC - Minting and burning of the ELC token Mints ELC amount to the recipient account. -Burns ELC amount from the account. +Burns ELC amount from the account. 2) rELP - Minting and burning of the rELP token Mints rELP amount to the recipient account. @@ -63,10 +68,11 @@ Mints some rELC amount, in exchange for some ELP amount. Mints some ELC and rELP amounts, in exchange for some ELP amount. Returns the amount of ELC and rELP. -ELCaim(after adjustment) = ELCaim(before adjustment) * (1+K) -LR = Value/P(ELP) * Amount(ELP) +ELCaim(after adjustment) = ELCaim(before adjustment) *(1+K) +LR = Value/P(ELP)* Amount(ELP) Where: + - Value is the value of the ELCs that have been issued - P isthe price of ELP - Amount is the number of ELP in reserve pool @@ -74,28 +80,28 @@ Where: When LR is lower than 0.3, the ELC system mints amounts of ELCs and rELPs, in exchange for amount of ELPs. -△Amount(rELP) = p(ELP) * △Amount(ELP) * (1-LR)/p(rELP) -△Amount(ELC) = p(ELP) * △Amount(ELP) * LR +△Amount(rELP) = p(ELP) *△Amount(ELP)* (1-LR)/p(rELP) +△Amount(ELC) = p(ELP) *△Amount(ELP)* LR When LR is higher than 0.3, the ELC system mints amount of rELPs only, in exchange for amount of ELPs. △Amount(rELP) = p(ELP) * △Amount(ELP) /p(rELP) -When ELC is higher than 102% of ELCaim and LR <= 0.7, the ELC system issues amount of ELC to rELP holders (95% of issued ELC) and the pool (5% of issued ELC). +When ELC is higher than 102% of ELCaim and LR <= 0.7, the ELC system issues amount of ELC to rELP holders (95% of issued ELC) and the pool (5% of issued ELC). When ELC is higher than 102% of ELCaim, if the multifunction pool has ELC, it swaps amount of ELCs for amount of ELPs, decreasing ELC supply. -When ELC is lower than 98% of ELCaim, the multifuncitonal pool swaps amount of ELPs for amount of ELCs. +When ELC is lower than 98% of ELCaim, the multifuncitonal pool swaps amount of ELPs for amount of ELCs. -When ELC is higher than 102% of ELCaim and LR is <= 0.7, when min (weighted average price of ELC 24 hours, weighted average price of ELC 1 hour) > $1, additional ELCs are issued, additional ELC will allocate to rELP liquidity provider (95% of issued ELC) and the multifunction pool (5% of issued ELC). +When ELC is higher than 102% of ELCaim and LR is <= 0.7, when min (weighted average price of ELC 24 hours, weighted average price of ELC 1 hour) > $1, additional ELCs are issued, additional ELC will allocate to rELP liquidity provider (95% of issued ELC) and the multifunction pool (5% of issued ELC). Number of additional ELCs for the day = min (weighted average price of ELCs 24 hours before monitoring point, weighted average price of ELCs 1 hour before monitoring point) /100 * number of ELCs before additional issuance. -Number of ELCs obtained by the rELP liquidity miner = number of additional ELCs issued on that day * 95% * miner’s share +Number of ELCs obtained by the rELP liquidity miner = number of additional ELCs issued on that day *95%* miner’s share Number of ELCs added to the multifunction pool as risk reserve fund = number of additional ELCs issued on the day * 5% When ELC is higher than 102% of ELCaim and LR > 0.7, the system will not issue any new ELCs, but will use the risk reserve fund (ELC) to swap amount of ELC for amount of ELP, which can decrease ELC price. -### Ecosystem Fit +### Ecosystem Fit Everlasting Cash is the stablecoin for the Cycan Network, which is a larger effort to build a decentralized autonomous trust (DAT) protocol for everyone to build business models in fintech and other fields within the Polkadot ecosystem. On the Cycan Network, for instance, anyone can launch a DeFi project, or build an investment portfolio and participate in the decision-making process for any DeFi product on the network. @@ -106,35 +112,44 @@ The Cycan Network (CYA) is an parachain built on the Polkadot network. The Everl ELC has a stable target pricing mechanism, called ELCaim. ELCaim is initially set as 1 USD and the pegged rate of ELCaim will be continuously adjusted and stabilized based on the anti-inflation factor (K), forming the anti-inflation algorithmic stablecoin mechanism. ELC not only uses crypto currencies as systemic reserves to decide the basic value of stablecoins, but also uses algorithms to control the supply of ELC so that the prices are at the same level of ELCaim. Users can use other cryptocurrencies including CYA, ELP, DOT, KSM, BTC, ETH and other digital assets proposed by the Cycan community to generate Everlasting Cash in the ELC protocol. Based on the Polkadot/Kusama ecosystem, Everlasting Cash will be playing a huge role in the future DeFi market, thanks to: -1. The adoption a crypto-collateralized mechanism to ensure the basic value of ELC. + +1. The adoption a crypto-collateralized mechanism to ensure the basic value of ELC. 2. The utilization of a reserve-based liquidity mining mechanism to issue additional ELC, so that ELC grows in an orderly manner with the expansion of demand. 3. The anti-inflation model, and using the anti-inflation factor K to adjust the ELCaim (the pegged rate). The annual appreciation rate of ELC is roughly the same as the inflation rate of USD. -4. The buffer mechanism with reserves for price falls, which avoid the death loop trap of algorithmic stablecoins. +4. The buffer mechanism with reserves for price falls, which avoid the death loop trap of algorithmic stablecoins. The ELC reserve pool will prioritize the tokens from the Polkadot system to build a solid stablecoin ecosystem. ## Team :busts_in_silhouette: -The team beyond Everlasting Cash is the Cycan team, an early-stage core pool of talents from around the world, with a background in finance, blockchain development and large-scale software architectures serving multiple industries, business development and media. + +The team beyond Everlasting Cash is the Cycan team, an early-stage core pool of talents from around the world, with a background in finance, blockchain development and large-scale software architectures serving multiple industries, business development and media. Cycan has a core team of developers numbering 10, including a development leader, 7 Rust developers, 1 product manager, and 1 front-end engineer. ### Team members + Cycan is directed by the following key roles: -* Donald Gao: founder, financial model designer -* Michele Ruberl, global tech partner, IT architect -* Vivi Lin, global partner, CMO + +- Donald Gao: founder, financial model designer +- Michele Ruberl, global tech partner, IT architect +- Vivi Lin, global partner, CMO ### Contact -* **Contact Name:** Donald Gao -* **Contact Email:** Donald@cycan.network -* Website http://cycan.network -### Legal Structure -* **Registered Address:** to be registered. -* **Registered Legal Entity:** Cycan Foundation is being registered in Singapore, ETA March 2021. +- **Contact Name:** Donald Gao + +- **Contact Email:** Donald@cycan.network +- Website http://cycan.network + +### Legal Structure + +- **Registered Address:** to be registered. + +- **Registered Legal Entity:** Cycan Foundation is being registered in Singapore, ETA March 2021. ### Team's experience + Cycan’s team has a long experience in the blockchain technology development and financial model designs. The team has developed public chains similar to Ethereum, cross-chain bridges connecting DPOS-based side chain and the notary network, and the open consortium chain with the rPBFT consensus mechanism. The team also has rich experience in smart contract development, including the Bancor-based decentralized transaction protocol, decentralized identity, distributed domain registration and auction, decentralized stable coin protocols, etc. @@ -147,80 +162,95 @@ Lastly, the team has a consolidated architectural and devops experience both in ### Team Code Repos -* ELP-Runtime-node: https://github.com/CycanTech/ELP-Runtime-node -* ELC-contracts: https://github.com/CycanTech/ELC + +- ELP-Runtime-node: https://github.com/CycanTech/ELP-Runtime-node + +- ELC-contracts: https://github.com/CycanTech/ELC ### Team LinkedIn Profiles -* https://www.linkedin.com/in/donald-gao-6bab74206/ -* https://www.linkedin.com/in/vivi-lin-1862276/ -* https://www.linkedin.com/in/mikrub/ + +- https://www.linkedin.com/in/donald-gao-6bab74206/ + +- https://www.linkedin.com/in/vivi-lin-1862276/ +- https://www.linkedin.com/in/mikrub/ -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: ### Overview -* **Total Estimate Duration:** 14 weeks -* **Full-time Equivalent(FTE):** 4 -* **Total cost:** 1500 USD (we accept up to 100% of payment in crypto currencies that are equivalent to $1,500 including DAI) + +- **Total Estimate Duration:** 14 weeks + +- **Full-time Equivalent(FTE):** 4 +- **Total cost:** 1500 USD (we accept up to 100% of payment in crypto currencies that are equivalent to $1,500 including DAI) ### Milestone 1 – Implement ELC contracts -* **Total Estimate Duration:** 8 weeks -* **Full-time Equivalent(FTE):** 2 -* **Total cost:** 1000 USD -* **Task:** to fulfill the ELC contracts development based on ink! + +- **Total Estimate Duration:** 8 weeks + +- **Full-time Equivalent(FTE):** 2 +- **Total cost:** 1000 USD +- **Task:** to fulfill the ELC contracts development based on ink! | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use ELC contract. | -| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | -| 1. | ELC contracts | Develop ELC contract implement ELC whitepaper | -| 1a. | Anti-Inflation Factor K & On-Chain Governance | As the Polkadot parachain, Cycan/ELP network generates a block every 6 seconds or so, and the ELCaim increases by K every 10,000 blocks. In the ELC network, K can be adjusted through the on-chain governance mechanism, which can be decided by public voting in the community. | -| 1b. | Liability Ratio | To swap digital assets into the ELC contract, in which one can obtain both ELC and the risk assets(rXXX) or only the risk asset(rXXX). The difference will be defined by the Liability Ratio(marked as LR). | -| 1c. | ELC Supply Expansion mechanism | When the prices of ELC exceed ELCaim, additional ELC will be issued and automatically allocated to the risk asset holders. | -| 1d. | ELC Supply Contraction | When the prices of ELC go lower than 0.98 ELCaim, the circulating ELC will be repurchased by the risk reserve fund, and this part of ELC will be temporarily taken out of circulation; when the prices of ELC start to go over ELCaim, the ELC will be sold with priority by the risk reserve fund to recover the reserve. | -| 1e. | Oracle Price acquirement | The oracle price adopts the dual price mechanism of Parachain DEX and Chainlink (or Zenlink). | +| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use ELC contract. | +| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | +| 1. | ELC contracts | Develop ELC contract implement ELC whitepaper | +| 1a. | Anti-Inflation Factor K & On-Chain Governance | As the Polkadot parachain, Cycan/ELP network generates a block every 6 seconds or so, and the ELCaim increases by K every 10,000 blocks. In the ELC network, K can be adjusted through the on-chain governance mechanism, which can be decided by public voting in the community. | +| 1b. | Liability Ratio | To swap digital assets into the ELC contract, in which one can obtain both ELC and the risk assets(rXXX) or only the risk asset(rXXX). The difference will be defined by the Liability Ratio(marked as LR). | +| 1c. | ELC Supply Expansion mechanism | When the prices of ELC exceed ELCaim, additional ELC will be issued and automatically allocated to the risk asset holders. | +| 1d. | ELC Supply Contraction | When the prices of ELC go lower than 0.98 ELCaim, the circulating ELC will be repurchased by the risk reserve fund, and this part of ELC will be temporarily taken out of circulation; when the prices of ELC start to go over ELCaim, the ELC will be sold with priority by the risk reserve fund to recover the reserve. | +| 1e. | Oracle Price acquirement | The oracle price adopts the dual price mechanism of Parachain DEX and Chainlink (or Zenlink). | ### Milestone 2 – Extend functions of the ELC contract. -* **Total Estimate Duration:** 6 weeks -* **Full-time Equivalent(FTE):** 2 -* **Total cost:** 500 USD -* **Task:** Implement new contract functions based on ink! and develop DAPP front-end. + +- **Total Estimate Duration:** 6 weeks + +- **Full-time Equivalent(FTE):** 2 +- **Total cost:** 500 USD +- **Task:** Implement new contract functions based on ink! and develop DAPP front-end. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | -| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use product. | -| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | -| 1a. | ELC contract extension: Liquidity Mining Pool | ELP reserves a certain percentage of tokens to reward participants generatingELC, which means that part of the tokens will be given to risk asset (rELP) holders. | -| 1b. | ELC contract extension: Risk Reserve Fund | 1) A total of 21 million ELPs, of which 1 million ELPs are deposited into the risk reserve fund as the initial risk reserve. 2) In the ELC supply expansion process, 5% of the additional ELC issued through the algorithmic mechanism is converted into ELP and deposited in the risk reserve fund. | -| 2a. | ELC Dapp | 1) ELC generation function. 2) Redemption of the pledged assets function. 3) ELC price, issuance volumes, risk assets, debt ratios and other query functions. 4) Liquidity mining function. And integrate with the wallet. | +| 0a. | License | GNU General Public License v3.0 / Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a tutorial that explains how a user can use product. | +| 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | +| 1a. | ELC contract extension: Liquidity Mining Pool | ELP reserves a certain percentage of tokens to reward participants generatingELC, which means that part of the tokens will be given to risk asset (rELP) holders. | +| 1b. | ELC contract extension: Risk Reserve Fund | 1) A total of 21 million ELPs, of which 1 million ELPs are deposited into the risk reserve fund as the initial risk reserve. 2) In the ELC supply expansion process, 5% of the additional ELC issued through the algorithmic mechanism is converted into ELP and deposited in the risk reserve fund. | +| 2a. | ELC Dapp | 1) ELC generation function. 2) Redemption of the pledged assets function. 3) ELC price, issuance volumes, risk assets, debt ratios and other query functions. 4) Liquidity mining function. And integrate with the wallet. | ## Future Plans + Our team would like to make continuous contributions to the Substrate and Polkadot ecosystems. Our future plans are as follows: - • Everlasting Cash is only deployed in the Polkadot ecosystem, through the Runtime module using the Substrate framework. - • The ELC reserve pool will prioritize tokens from the Polkadot system to build a solid stablecoin ecosystem. - • To provide the users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. + • Everlasting Cash is only deployed in the Polkadot ecosystem, through the Runtime module using the Substrate framework. + • The ELC reserve pool will prioritize tokens from the Polkadot system to build a solid stablecoin ecosystem. + • To provide the users in the Polkadot ecosystem with a stablecoin that appreciates naturally and achieves the goal of anti-inflation. Everlasting Cash will exist as an independent asset in the Polkadot ecosystem, and will also power the Cycan decentralized autonomous trust (DAT) on the path to revolutionize trust in the financial market. -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: + +- What work has been done so far? -* What work has been done so far? - 1) The development of the initial version of the Substrate-based Pheonix test chain has been completed, supporting the WASM and EVM virtual machines. - 2) The DAO self-governance Runtime module and the application for the access to the Rococo test network are in progress. - 3) The development plan for the ELC contract has been formulated and the development is in progress. + 1) The development of the initial version of the Substrate-based Pheonix test chain has been completed, supporting the WASM and EVM virtual machines. + 2) The DAO self-governance Runtime module and the application for the access to the Rococo test network are in progress. + 3) The development plan for the ELC contract has been formulated and the development is in progress. + +- Are there are any teams who have already contributed (financially) to the project? -* Are there are any teams who have already contributed (financially) to the project?
           No -* Have you applied for other grants so far?
          +- Have you applied for other grants so far? +  No -* Are there any other project similar to yours?
          +- Are there any other project similar to yours? +  To the best of our knowledge, there is no project about anti-inflation stablecoin that is similar to our project. Please let us know if there are any. diff --git a/applications/FIAT-on-off-ramp.md b/applications/FIAT-on-off-ramp.md index 17ed724d6c5..fabf5a628fb 100644 --- a/applications/FIAT-on-off-ramp.md +++ b/applications/FIAT-on-off-ramp.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# FIAT on-off-ramp -* **Project Name:** FIAT on-off-ramp * **Team Name:** element36 * **Payment Address:** Ethereum 0x56788E08C97d2677DAdED801e69bfE5D33ddACD5 @@ -255,17 +254,17 @@ For this proposal we focus on building a simple substrate based chain containing ### Milestone 3 Documentation & Demo-Dapp -* **Estimated Duration:** 1 month +* **Estimated Duration:** 1.5 month * **FTE:** 1 * **Costs:** 5.000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Tutorial | Installation instruction with "Hello World" example. We want to provide a similar repos like the ones used by our Ethereum solution: https://github.com/element36-io/cash36-ping and a "buy me a coffee" demo app similar to that one here: https://github.com/element36-io/cash36-examples | -| 1. | Coffee Smart Contract | A "buy me a coffee" contract. It will accept a payment and cash out automatically to the benefit of a hardcoded recipient who will be receiving the funds in FIAT. | -| 2. | Dapp | The Dapp which uses the "by me a coffee" Smart Contract. | -| 3. | Docker-Compose: node & Dapp | We will add the Dapp to the docker-compose file of Milestone 2 to demonstrate the full functionality of our chain, the ocw, including a proxy for the FIAT Rest Interface developed in Milestone 1 and the "buy me a coffee" Dapp. | +| 0b. | Tutorial | We will provide a tutorial for using the following app for two different scenarios: donating with stablecoin and donating via bank transfer that ends up in the chain. | +| 1. | Buy me a coffee dApp | DApp where users can accept donations in stablecoin or via bank transfer, similar to **Buy Me a Coffee** service. This will consist of a frontend app in React which serves as an interface for interacting with the chain. Users will be able to link their on-chain `AccountId` to their bank account details (IBAN, balance, etc.), withdraw on-chain balance to their bank account and transfer funds in the bank account via on-chain extrinsic. | +| 2. | Docker-Compose: node & Dapp | We will add the Dapp to the docker-compose file of Milestone 2 to demonstrate the full functionality of our chain, the ocw, including a proxy for the FIAT Rest Interface developed in Milestone 1 and the "buy me a coffee" Dapp. | + ## Future Plans First step is to prove technical feasibility and also to learn more about the concepts of the Polkadot ecosystem. We already have some ideas in which direction we want to continue, but that is to be validated. In other words - maybe our thoughts will not make sense once we know more :) So far, our next milestones and development goals: diff --git a/applications/Faucet.md b/applications/Faucet.md new file mode 100644 index 00000000000..b44e2a7cb52 --- /dev/null +++ b/applications/Faucet.md @@ -0,0 +1,117 @@ +# Generic sybil-resistant faucet + +- **Team Name:** MB Karolio reikalai +- **Payment Address:** 0xc3e6eFA4D0847203dD4E19B7D114516Eb45840EC (DAI) +- **Level:** 1 + +## Project Overview :page_facing_up: + +### Overview + +Sybil-resistant faucet is a generic browser-based faucet solution that can be used on any existing parachain (substrate-based chain, either pallets or ink! smart contracts). + +### Project Details + +#### Mockup + +![mockup](https://user-images.githubusercontent.com/3159964/182354014-6cee3694-af8a-4585-8eaf-348365981716.png) + +#### Technology stack + +- Next.js +- TypeScript +- Tailwind +- Redis +- @polkadot\{.js} + +#### Architecture + +![architecture](https://user-images.githubusercontent.com/3159964/182353857-8784b612-154f-458f-b7d8-b81e0fb51f90.png) + +#### Configuration + +To make the faucet generic, it will store its configuration settings in `.env` file which will include the following settings: + +- `DRIP_CAP` - how many tokens to send per drip +- `DRIP_DELAY` - how often user's can request to drip tokens (in ms) +- `REDIS_ENDPOINT` - Redis instance endpoint +- `RPC_ENDPOINT` - Substrate node endpoint +- `PORT` - Substrate node port +- `FAUCET_ACCOUNT_MNEMONIC` - mnemonic of faucet's wallet +- `NEXTAUTH_ENDPOINT` - authentication endpoint +- `NEXTAUTH_JWT_SECRET` - used to encrypt JWT tokens +- `TWITTER_CLIENT_ID` - Twitter client ID +- `TWITTER_CLIENT_SECRET` - Twitter client secret +- `GITHUB_CLIENT_ID` - GitHub client ID +- `GITHUB_CLIENT_SECRET` - GitHub client secret + +### Ecosystem Fit + +Many dApps are facing an issue where it’s difficult to onboard new users. Thus, the goal is to simplify the process by making it easier for parachain and dApp developers to spin up their own faucets, and give users free tokens without people exploiting the system. In order to make the system sybil-resistant, centralised solutions like Twitter or GitHub login will be integrated, that will uniquely identify users, and enable dripping tokens to the account only once per given time period. + +Some similar projects include: +- https://github.com/paritytech/substrate-matrix-faucet +- https://github.com/OAXFoundation/substrate-faucet + +## Team :busts_in_silhouette: + +### Team members + +- Karolis Ramanauskas: full-stack developer & product designer + +### Contact + +- **Contact Name:** Karolis Ramanauskas +- **Contact Email:** hi@krl.is +- **Website:** https://krl.is/ + +### Legal Structure + +- **Registered Address:** Liepų g. 83, Klaipėda 92195 +- **Registered Legal Entity:** MB Karolio reikalai + +### Team's experience + +Karolis is product-minded software engineer who enjoys the challenge of creating pleasant, easy-to-use user experiences. He has worked on large-scale projects for his employers, as well as side-projects of his own. Some of the most notable experiences include building observability tools used by thousands of engineers at Uber that alert and help resolve new incidents, and enable to build more reliable services. He has also worked on a design system for Volvo Cars, and then became responsible for building tools to replace existing translation processes at the company to make them more effective. + +### Team Code Repos + +- * https://github.com/karooolis + +### Team LinkedIn Profiles + +- * https://www.linkedin.com/in/karolisram/ + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 1 month +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 4,000 USD + +### Milestone 1 — Implement the Faucet + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 4,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | I will provide both **inline documentation** of the code and a **tutorial** that explains how a developer can spin up his/her own faucet. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, I will describe how to run these tests. | +| 0d. | Article | I will publish an **article** that explains how the faucet works, why it was created, and how it can be used by developers. +| 1. | User Interface | I will create faucet UI with Tailwind. It will include address form, login buttons, as well as error and success states. | +| 2. | Authentication | I will create a module for 0Auth user authentication that will uniquely identify users and make faucet sybil-resistant. | +| 3. | User status | I will create a module for checking whether user is eligible to receive free tokens. | +| 4. | Faucet drip | I wil create a module that will send user free tokens if eligible. | + +## Future Plans + +- Keep adding additional 0Auth options or other features if needed. +- Keep maintaining the project in case of potential issues. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Developer DAO diff --git a/applications/Fennel_Protocol.md b/applications/Fennel_Protocol.md index 284a3e322c3..6851aee93c6 100644 --- a/applications/Fennel_Protocol.md +++ b/applications/Fennel_Protocol.md @@ -1,9 +1,8 @@ -# W3F Grant Proposal +# Fennel Protocol -* **Project Name:** Fennel Protocol -* **Team Name:** Fennel Labs -* **Payment Address:** 0xF505894841d53AaBDe6EdeA7C5970fFe3A0240b2 (DAI) -* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Team Name:** Fennel Labs +- **Payment Address:** 0xF505894841d53AaBDe6EdeA7C5970fFe3A0240b2 (DAI) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview :page_facing_up: @@ -15,10 +14,10 @@ This grant proposal describes the first step of a long-term plan to develop Fenn The background of the Whiteflag specification is as follows: -> Current armed conflicts are highly complex, because of the sheer number of parties involved: regular military forces, armed groups, peacekeeping forces, neutral parties such as journalists and non-governmental human-rights and aid organisations, civilians, refugees etc. Even though parties are opposing forces, or neutral organisations that do not want to show any affiliation, they do require to quickly and directly communicate to one or more other parties involved in the conflict in different situations. ->

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

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

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

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

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

          All in all, the protocol forms the basis for a neutral and open network, the Whiteflag Network, for trusted real-time messaging between parties in conflicts and disaster response. One can find more details about the Whiteflag Protocol specification by clicking on these links: @@ -71,109 +70,125 @@ Though applications are planned, they are beyond scope for this proposal. ### Team members -* Sean Batzel -* Isaac Adams -* Andre Vanoncini -* Fernando Fonseca-Avalos -* Mateusz Plaza -* Jan Eberle +- Sean Batzel +- Isaac Adams +- Andre Vanoncini +- Fernando Fonseca-Avalos +- Mateusz Plaza +- Jan Eberle ### Contact -* **Contact Name:** Fennel Labs Core Team -* **Contact Email:** info@fennellabs.com -* **Website:** www.fennellabs.com +- **Contact Name:** Fennel Labs Core Team +- **Contact Email:** info@fennellabs.com +- **Website:** www.fennellabs.com ### Legal Structure -* **Registered Address:** 1309 Coffeen Avenue Suite 1200, Sheridan, Wyoming 82801 -* **Registered Legal Entity:** Fennel Labs, LLC. +- **Registered Address:** 1309 Coffeen Avenue Suite 1200, Sheridan, Wyoming 82801 +- **Registered Legal Entity:** Fennel Labs, LLC. ### Team's experience #### Sean Batzel -* Development Team co-lead for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. -* 2 years as lead and only developer of fEMR OnChain, a modular EMR software targeting eventual decentralization. -* 10 years of programming and software development experience -* 5 years of experience as lead/primary developer on expansive projects -* 2 years experience in remote development team coordination -* Graduate-level research experience studying blockchain’s uses in high-level information networks -* Dedicated focus on exploring use cases for blockchain and decentralized consensus beyond cryptocurrency and fusing Web 2 and Web 3 applications in a way that eases the industry’s transition to more decentralized computing + +- Development Team co-lead for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. + +- 2 years as lead and only developer of fEMR OnChain, a modular EMR software targeting eventual decentralization. +- 10 years of programming and software development experience +- 5 years of experience as lead/primary developer on expansive projects +- 2 years experience in remote development team coordination +- Graduate-level research experience studying blockchain’s uses in high-level information networks +- Dedicated focus on exploring use cases for blockchain and decentralized consensus beyond cryptocurrency and fusing Web 2 and Web 3 applications in a way that eases the industry’s transition to more decentralized computing #### Isaac Adams -* Succesfully launched [savvi](https://savvi.com) as tech lead and developed the jwt authentication, sign in/out, cart, and checkout features on the application while helping manage other developers working on the project -* Open source contributions: [added missing rpc method](https://github.com/harmony-one/sdk/pull/82) to harmony-one blockchain's npm package, [json ld transformer](https://github.com/parcel-bundler/parcel/pull/4397) for parcel v2, and extending usage of action-download-artifact to support the [github.ref variable](https://github.com/dawidd6/action-download-artifact/pull/55) -* Published author for [research](https://www.mdpi.com/2571-6182/1/1/1) on the degradation of antibiotics using a plasma apparatus -* 4 years of experience development experience on a wide range of projects, including web applications built using react/angular|.net core|SQL, labview applications for lab experiments, and devops/cloud operations -* 1 year of experience of being tech lead on two successfully launched web projects -* Graduated from Drexel University with a B.S. in Chemical Engineering + +- Succesfully launched [savvi](https://savvi.com) as tech lead and developed the jwt authentication, sign in/out, cart, and checkout features on the application while helping manage other developers working on the project + +- Open source contributions: [added missing rpc method](https://github.com/harmony-one/sdk/pull/82) to harmony-one blockchain's npm package, [json ld transformer](https://github.com/parcel-bundler/parcel/pull/4397) for parcel v2, and extending usage of action-download-artifact to support the [github.ref variable](https://github.com/dawidd6/action-download-artifact/pull/55) +- Published author for [research](https://www.mdpi.com/2571-6182/1/1/1) on the degradation of antibiotics using a plasma apparatus +- 4 years of experience development experience on a wide range of projects, including web applications built using react/angular|.net core|SQL, labview applications for lab experiments, and devops/cloud operations +- 1 year of experience of being tech lead on two successfully launched web projects +- Graduated from Drexel University with a B.S. in Chemical Engineering #### Andre Vanoncini -* Working with the Google Tango tablet for my master thesis (C++, first in depth steps for me with git and linux) -* Developing and implementing a focussing tool and process in C++ with Qt QML GUI -* Getting Inference working with libtorch (C++) and JNI -* Understanding compilation of C++ with cmake and being able to compile on the command line instead of the green play buttons + +- Working with the Google Tango tablet for my master thesis (C++, first in depth steps for me with git and linux) + +- Developing and implementing a focussing tool and process in C++ with Qt QML GUI +- Getting Inference working with libtorch (C++) and JNI +- Understanding compilation of C++ with cmake and being able to compile on the command line instead of the green play buttons #### Fernando Fonseca-Avalos -* Experience with C/C++, Python, JavaScript -* Developing proficiency with Rust. + +- Experience with C/C++, Python, JavaScript + +- Developing proficiency with Rust. #### Mateusz Plaza -* Captain for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. -* 8 years of experience working in high performance medical units -* 2 years of experience leading medical humanitarian teams in Central America -* 2012 Fulbright Research Fellow: completed research project on Poland's Solidarity Movement, exploring methods of self-organization and coordination of social movements that leverage symbols as a form of empowerment and that resist the threat of disinformation/active measures/propaganda. -* Published blockchain researcher, with a focus on the epistemic significance of decentralized blockchain ledgers, especially in terms of Self Sovereign Identity, Decentralized Autonomous Organization, and AI Ontology. + +- Captain for Theriak, a project which won the 2020 Odyssey Momentum hackathon's Conflict Prevention track. + +- 8 years of experience working in high performance medical units +- 2 years of experience leading medical humanitarian teams in Central America +- 2012 Fulbright Research Fellow: completed research project on Poland's Solidarity Movement, exploring methods of self-organization and coordination of social movements that leverage symbols as a form of empowerment and that resist the threat of disinformation/active measures/propaganda. +- Published blockchain researcher, with a focus on the epistemic significance of decentralized blockchain ledgers, especially in terms of Self Sovereign Identity, Decentralized Autonomous Organization, and AI Ontology. #### Jan Eberle -* Experience distinguishing misinformation, disinformation, and combatting the infodemic as a Media Analyst -* Strong communications & usability experience from linguistic studies -* Writing documents for different channels/audiences as a technical writer -* Practical peace keeping experience as a swiss guard in the Vatican + +- Experience distinguishing misinformation, disinformation, and combatting the infodemic as a Media Analyst + +- Strong communications & usability experience from linguistic studies +- Writing documents for different channels/audiences as a technical writer +- Practical peace keeping experience as a swiss guard in the Vatican #### Advisors -* Andrew Plaza -* Zbigniew Zielinski + +- Andrew Plaza + +- Zbigniew Zielinski ### Team Code Repos -* https://github.com/Romulus10 -* https://github.com/isaacadams -* https://github.com/vanandre -* https://github.com/fennelLabs -* https://github.com/Romulus10/infostratus -* https://github.com/Romulus10/blockchain_message -* https://github.com/fennelLabs/Theriak +- https://github.com/Romulus10 +- https://github.com/isaacadams +- https://github.com/vanandre +- https://github.com/fennelLabs +- https://github.com/Romulus10/infostratus +- https://github.com/Romulus10/blockchain_message +- https://github.com/fennelLabs/Theriak ### Team LinkedIn Profiles (if available) -* https://www.linkedin.com/in/seanbatzel/ -* https://www.linkedin.com/in/mateusz-p-6b126424/ -* https://www.linkedin.com/in/jan-eberle-553110195/ -* https://www.linkedin.com/in/fernando-fonseca-avalos-a0a516224/ -* https://www.linkedin.com/in/andreva/ -* https://www.linkedin.com/in/isaacdadams/ +- https://www.linkedin.com/in/seanbatzel/ +- https://www.linkedin.com/in/mateusz-p-6b126424/ +- https://www.linkedin.com/in/jan-eberle-553110195/ +- https://www.linkedin.com/in/fernando-fonseca-avalos-a0a516224/ +- https://www.linkedin.com/in/andreva/ +- https://www.linkedin.com/in/isaacdadams/ ### Ecosystem Fit + Fennel Protocol's key and identity management functionality is fine-tuned for decentralized communication that makes use of pre-defined signals and signs; for example, the Whiteflag specification uses predefined signals and signs derived from International Humanitarian Law, the CRED Disaster Category Classification, and the OECD Economic Infrastructure Common Reporting Standard Codes. Future proposals will build up Fennel Protocol to accomodate the full extent of the Whiteflag Protocol specification. Substrate's interoperability will provide the Polkadot ecosystem with a shared conception of Whiteflag Protocol's predefined signals and signs; -this will allow users to seemlessly send Whiteflag messages across the decentralized Polkadot ecosystem. Critically, an interoperable Whiteflag Network ensures situational awareness is not siloed but is unified in critical use cases. This helps decision makers receive a full picture of the field of operations. +this will allow users to seemlessly send Whiteflag messages across the decentralized Polkadot ecosystem. Critically, an interoperable Whiteflag Network ensures situational awareness is not siloed but is unified in critical use cases. This helps decision makers receive a full picture of the field of operations. #### Whiteflag Section 2.5: Minimally Viable Implementation: -Fennel Protocol will implement the minimally viable implementation of the Whiteflag functionality that allows for the sending of Whiteflag messages. + +Fennel Protocol will implement the minimally viable implementation of the Whiteflag functionality that allows for the sending of Whiteflag messages. We will implement further components of Whiteflag in further proposals. Whiteflag section 2.5 states: any implementation of the Whiteflag Protocol that sends messages on the Whiteflag Network, must implement at a minimum the following functionality: -* The Whiteflag Authentication message with at least one authentication option. At release, both Shared Secret and External Resource Authentication will be fully supported. +- The Whiteflag Authentication message with at least one authentication option. At release, both Shared Secret and External Resource Authentication will be fully supported. -* The possibility to Recall, Update and Discontinue (Whiteflag Reference Codes 1, 2 and 4) any implemented sign or signal, if such Reference Type is valid i.a.w. Reference options. These will be implemented as low-level Fennel messages through the Sign extrinsic call, effectively creating a specialized transaction subtype for each of these. +- The possibility to Recall, Update and Discontinue (Whiteflag Reference Codes 1, 2 and 4) any implemented sign or signal, if such Reference Type is valid i.a.w. Reference options. These will be implemented as low-level Fennel messages through the Sign extrinsic call, effectively creating a specialized transaction subtype for each of these. Fennel Protocol will provide the Substrate infrastructure for two authentication methodologies that abide by Whiteflag Protocol’s specification. -* Method 1, External Resource Authentication: requires the user to declare their identity in some public and trusted place which can be referenced in their activities. This often requires a strong proof, such as a cryptographic signature and public key declaration, that can be verified to prove that a transaction comes from the identity declared. +- Method 1, External Resource Authentication: requires the user to declare their identity in some public and trusted place which can be referenced in their activities. This often requires a strong proof, such as a cryptographic signature and public key declaration, that can be verified to prove that a transaction comes from the identity declared. -* Method 2, Shared Secret Authentication: requires an end user to establish a token known only to themselves and some authentication authority, similar to a password in more Web 2.0-oriented authentication. +- Method 2, Shared Secret Authentication: requires an end user to establish a token known only to themselves and some authentication authority, similar to a password in more Web 2.0-oriented authentication. Fennel Protocol will support both of these authentication mechanisms at launch, with shared secrets covered by our encrypted channel mechanism and external resources declared and submitted as public transactions through the Identity Update extrinsic. @@ -195,15 +210,15 @@ Fennel Protocol will also include support for RSA with a minimal key size of 409 ### Overview -* **Total Estimated Duration:** 3 months -* **Full-Time Equivalent (FTE):** 3 FTE -* **Total Costs:** 50,000 USD +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 50,000 USD ### Milestone 1 — Implement Substrate Modules -* **Estimated duration:** 1 months -* **FTE:** 3 -* **Costs:** 15,000 USD +- **Estimated duration:** 1 months +- **FTE:** 3 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -222,9 +237,9 @@ Fennel Protocol will also include support for RSA with a minimal key size of 409 ### Milestone 2 — Additional features -* **Estimated duration:** 1 months -* **FTE:** 3 -* **Costs:** 15,000 USD +- **Estimated duration:** 1 months +- **FTE:** 3 +- **Costs:** 15,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -240,9 +255,9 @@ Fennel Protocol will also include support for RSA with a minimal key size of 409 ### Milestone 3 — Additional features -* **Estimated duration:** 1 months -* **FTE:** 3 -* **Costs:** 20,000 USD +- **Estimated duration:** 1 months +- **FTE:** 3 +- **Costs:** 20,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -266,8 +281,8 @@ identity and signaling applications should be able to easily build on the runtim ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** -We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members. +**How did you hear about the Grants Program?** +We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members. Thus far, we've ported our Theriak repository to the most recent version of Substrate as of writing of this application. Financial contribution has not yet begun for the Fennel Protocol project. diff --git a/applications/FuturFusion.md b/applications/FuturFusion.md new file mode 100644 index 00000000000..1dfbedb3747 --- /dev/null +++ b/applications/FuturFusion.md @@ -0,0 +1,202 @@ +# Futur & Fusion Protocols + +- **Team Name:** Relai Network +- **Payment Address:** 15ZybdjAomB2gYWzY9mC1iPCK72zKCuJ14jZmjQ8FsFXphmV (USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + +### Futur-Fusion Protocol + +In the current digital landscape, the app store ecosystem grapples with challenges, primarily attributed to the dominance of major players like Apple's App Store and Google's Play Store. This concentration of power sparks concerns about anti-competitive practices, high developer fees, and a lack of user control entrenched in enclosed platforms and proprietary policies. + +However, these challenges serve as potential catalysts for innovation, especially considering regulatory changes in major regions that hint at the possibility of alternative stores. Surveys indicate a growing consumer appetite for privacy protections, web3 integration, and community governance, values inherent in decentralized solutions. + +Enter the Relai Network, positioned as a catalyst for reshaping this landscape and addressing these challenges. It recognizes the need for a new smartphone era that prioritizes enhanced user privacy and security. Operating on privacy-focused systems, these devices provide a secure alternative, diverging from the intrusive data practices characteristic of traditional smartphones and other devices. + +Simultaneously, in acknowledgment of the proven utility of Web3 technologies, the network seamlessly integrates these principles into the mobile experience. By fostering the development of Web3-capable devices, the network propels the adoption of decentralized technologies. This intelligent synthesis of Web3-capable devices with privacy-focused operating systems establishes a powerful synergy, enabling users to fully embrace the benefits of the decentralized web with enhanced privacy. + +The [Relai Network](https://relai.network/) is not only committed to reimagining app distribution and development while ensuring privacy but also to subtly advancing the widespread adoption of Web3. This commitment marks the dawn of an era defined by user-centric, secure, and decentralized interactions. + +### Project Details + +In line with the overarching vision of the Relai Network, the project unfolds as a comprehensive solution, seamlessly integrating mobile operating systems and establishing cutting-edge hardware partnerships for the next generation. This strategic approach comprises two vital components: + +**1. Futur Protocol:** + +**Objective:** Creating a decentralized app store to establish a transparent, user-centric app distribution ecosystem, leveraging the power of blockchain technology. + +**Benefits:** Empowering developers, reducing fees, eliminating censorship, and fostering innovation, thereby expanding user choice in the app ecosystem. + +**2. Fusion Protocol:** + +**Objective:** Tackling privacy concerns and optimizing mobile devices for smooth web3 experiences. + +**Features:** The Fusion Protocol proposes a collaborative approach with OEMs (phone manufacturers) to embed essential elements such as privacy-focused operating systems (e.g., GrapheneOS, PureOS, ...) and integrated security modules (Vaults, TEE, Secure Enclaves, ...) by default. These modules are designed for managing wallets and sensitive data. + +**Benefits:** + +**Collaborative Privacy-Focused Ecosystem:** +Phones manufactured through this partnership would offer a complete privacy-centric ecosystem, embedding privacy-focused OS (like GrapheneOS, ...) alongside the decentralized and privacy-focused app distribution of the FuturStore. Additionally, it opens the possibility of white-label devices by the Relai Network. + +**Seamless Web3 Experience and Enhanced Security:** +Users gain more options for securely interacting with decentralized applications while effectively managing their assets. This ensures a user-friendly and secure experience within the evolving landscape of web3 technologies. + +#### Components + +- **Relai Network:** A Substrate-based blockchain serving as the host for the Futur and Fusion protocols, along with additional components planned for subsequent phases. + +- **Futur Protocol:** A suite of pallets responsible for managing the fundamental logic of the app store within the RELAI network. + +- **Futur Store Mobile App:** The mobile application designed for accessing the app store. + +- **Futur Store Console:** A web application portal facilitating app submission and lifecycle management within the Futur Store ecosystem. + +- **Storage Layer:** Layer dedicated to storing validated APKs and IPAs(for iOS). IPFS and/or [Crust Network](https://www.crust.network/). Crust integrate IPFS and have pinning features and also is a parachain in the Polkadot ecosystem. + +- **SAST/DAST Module:** Static and Dynamic Analysis component for scanning submited apks for checking security (initially interfacing with + [MobSF: Mobile Security Framework](https://github.com/MobSF/Mobile-Security-Framework-MobSF) Web API). + +- **Fusion Protocol:** A suite of pallets integral to the Fusion Protocol, focusing on managing OEMs or Device Manufacturer partners associated with the protocol. + +- **Fusion Console:** A web application portal tailored for OEM partners involved in the Fusion Protocol. + +- **Fusion Marketplace:** The marketplace dedicated to the Fusion protocol, facilitating interactions and transactions within the ecosystem. + +- **OS Catalog:** A repository consolidating references to open-source, privacy-focused Operating Systems intended for use by protocol partners. This includes "De-Googled Android AOSP" variants (such as GrapheneOS, /e/ Foundation, LineageOS), "Linux Phone OS" options (Ubuntu Touch, PostmarketOS, PureOS) + + +### Ecosystem Fit + +The Relai Network will integrates into the Polkadot ecosystem, positioning itself as an indispensable component by adopting Substrate as its foundational framework. This strategic choice ensures not only scalability, security, and but also facilitates ease of customization. Devices generated through the Fusion protocol are designed for compatibility with chains and Dapps within the DotSama ecosystem and beyond. + +The target audience for the Relai Network is diverse and includes: + +- Web3 Users +- Apps and Games Developers +- OEMs (Original Equipment Manufacturers) or Device Manufacturers +- Mobile App/Games Users +- Users of Mobile Apps and Dapps + +Here is a diagram of the project + +![Figure 1-1](https://raw.githubusercontent.com/RELAI-Network/docs/main/archi/architechture.jpg?raw=true) + +[Future Console Wireframes](https://docs.google.com/presentation/d/1UsVMwi_ibrn2op3FutWle7QkK2pP060usgEyvBv9PiQ) + +## Team :busts_in_silhouette: + +### Team members +- Mor GUEYE + +### Contact + +- **Contact Name:** Mor GUEYE +- **Contact Email:** gueyemor2009@gmail.com +- **Website:** [relai.network](https://relai.network/) + +### Legal Structure + +- **Registered Address:** Sicap Mbao, Dakar Senegal +- **Registered Legal Entity:** Ridone Technologies. + +### Team's experience + +Mor is a seasoned software engineer with over a decade of experience in the field. He has been involved in numerous projects related to web2 and web3 development. On Web3 side, he has contributed to Polkadot ecosytem projects such as Ternoa and Pendulum chain. + +### Team Code Repos + +| Domain | Repo | +| - | - | +| Relai Network chain | https://github.com/RELAI-Network/relai-network | +| Futur Protocol Runtime Modules | https://github.com/RELAI-Network/futurprotocol | +| Futur Store app | https://github.com/RELAI-Network/FuturStore | +| Futur Console | https://github.com/RELAI-Network/FuturStore-console | +| Fusion Protocol Runtime Modules | https://github.com/RELAI-Network/fusion-protocol | +| Fusion Console | https://github.com/RELAI-Network/fusionconsole | +| Fusion Marketpalce | https://github.com/RELAI-Network/fusionmarketplace | +| AI Models Hub | https://github.com/RELAI-Network/ai-models | + +## Development Status :open_book: + +The project is splitted into phases: + +1. Phase 1: Foundation +2. Phase 2: Building +3. Phase 3: Expansion + +This current application focuses on putting in place the Futur Protocol which comprised of: + +- **Futur Protocol Runtime Modules** +- **Futur Console** +- **FuturStore Mobile app** +- **SAST/DAST Module** +- **Storage Layer** + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 1,5 Months +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 7,000 USD + +### Milestone 1 — Futur Protocol + +- **Estimated duration:** 1,5 month +- **FTE:** 1 +- **Costs:** 7,000 USD + + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a **gituhb repo readmes** that explains how to deploy mobile app on the FuturStore. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. The **github repo readme** we will also describe how to run these tests. | +| 0d. | Articles |Articles explaining the FuturStore stack will be published. There will be article for FuturStore users and also for App developers wanting to submit apps on the store. | +| 1. | FuturStore Mobile app | A **Flutter** mobile app store, displays catalog of published apps. Users can browse and install available apps. | +| 2. | Futur Protocol Runtime modules | Suite of pallets that will contain the logic of the Futurstore | +| 2.a | **DevRegistry Pallet** | Manages the registration of developers with functionnalities like: RegisterDev,... | +| | RegisterDev | Extrinsic called by app developer from the console to register a developer account (address and other metadata) and pay the registration fee (akin to paying the 25$ developer registration fee in Google Playstore or 99$ Apple app store fee).| +| | UnRegisterDev | Unregister a developer account )| +| 2.b | **AppRegistry Pallet** | functionnalities: Submit, Publish, Unpublish, Update, BuyApp, Review and SetStoreRegistrationFee.**metadata** | +| | BuyApp | Extrinsic called **app user** from the mobile app using the app integrated wallet to buy the app. | +| | SubmitApp | Extrinsic called by **app developer** from console to submit app metadata. | +| | PublishApp | Extrinsic called by **app developer** from console to publish a submited app. An app can be submited and be unpublished (like in other stores, a developer can unpublish an app) | +| | UnPublishApp | Extrinsic called by **app developer** from console to unpublish a submited app.| +| | DeleteApp | Extrinsic called by **app developer** to remove the app from it's catalog | +| | SetStoreRegistrationFee | Extrinsic called by **sudo or collective** for setting developer registration fee | +| | - | VerifyAppReview : function - The backend server queues up these off-chain review requests. Off-chain worker on the Substrate node periodically checks this queue and grabs review requests.It uses the public key and signature to verify the review signature matches. This proves the review came from that user and then will be stored on-chain| +| | - | SubmitScan : function - called by off-chain worker and (communicate with **SAST/DAST Module** ) | +| | - | FetchScanResults : function - off-chain worker to communicate with **SAST/DAST Module** and according to the scan results if an app is qualified it will be published, if not the app developer will receive a notification on the console to take action accordingly | +| 3 | SAST/DAST Module | Static and Dynamic Analysis component for scanning submited apks for checking security (initially interfacing with [MobSF: Mobile Security Framework](https://github.com/MobSF/Mobile-Security-Framework-MobSF) Web API initially. Coordinating with the backend and off-chain workers. | +| 4 | Futur Console | Web portal for app developers for app submission and management (similar to google play console); **Angular or Flutter Web** | +| 5 | Backend Server| Serving as the API endpoint and also help in off-chain tasks, ex: Queuing and verifying off-chain review signatures before ingesting them on-chain via the off-chain worker,... | +| 6 | Storage Layer | IPFS and/or Crust Network ( or Rocky Crust Testnet) in development phase| + + + +## Future Plans + +The next step will be the Fusion protocol and after achieving those 2 milestones representing the foundations and serving as the bedrock for initiating governance features, fortifying the codebase, expanding the community. This will also set the stage for a range of advancements and expansions that are on RELAI Network roadmap such as: + +* Decentralized Computing and Storage: +* White-Labeling and Private Enterprise Stores: +* Peer-to-Peer Payments: + * Enables direct profits for developers. + * Bypasses high commissions from major platforms. +* Phone White Labeling for Fusion Protocol: + * Ventures into phone white labeling partnerships. + * Enhances user choices in decentralized mobile devices. +* AI Support: + * Utilizes AI for marketplace management. + * Incentivizes AI marketplaces contributing to protocol development. +* In-Store Advertising: + * Introduces user-centric advertising with privacy in mind. + * Enhances targeted advertising for a symbiotic developer-user relationship. +* Extension of Fusion Protocol: + * Envisions diversification beyond smartphones. + * Includes Smart TVs, Smartwatches, and innovative gadgets. + * Enhances privacy and security across various devices. + * Paves the way for a holistic, interconnected ecosystem of privacy-focused technologies. \ No newline at end of file diff --git a/applications/FuzzLand.md b/applications/FuzzLand.md new file mode 100644 index 00000000000..76e3cc77de6 --- /dev/null +++ b/applications/FuzzLand.md @@ -0,0 +1,402 @@ +# FuzzLand + +- **Team Name:** FuzzLand +- **Payment Address:** 0x3a2a700d9d822D23D3F0F55F4b097753b5B2FC9A (ERC20 DAI/USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1499#issuecomment-1634849391) + +## Project Overview :page_facing_up: + +### Overview + + +tldr: FuzzLand is a DAO leveraging crowd-sourced computation power to achieve **fast**, **accurate**, and **cheap** automated auditing. + +The importance of auditing has grown significantly in recent years as organizations strive to ensure the integrity and security of their systems. However, despite the importance of auditing, it remains challenging, with many auditing companies struggling to provide comprehensive and accurate reports. + +The use of human auditors by auditing firms presents several challenges, including the high costs of recruiting and training qualified personnel and the potential for human error. With the increasing complexity of software systems and the growing volume of data to be analyzed, manual audits can become increasingly time-consuming and error-prone. On the other hand, automated auditing solutions also present their own set of challenges. These solutions typically require high computational power and incur high running time overhead. Thus, many traditional automated auditing tools sacrifice completeness and soundness of the analysis for faster response time, resulting in both false negative and positive results. + +In contrast, FuzzLand aims to parallelize novel automated program analysis techniques to gain accurate results in a reasonable amount of time. To achieve high parallelism with low costs, FuzzLand platform allows the public to contribute computation power to accomplish the automated auditing in return for token rewards. In the meantime, all the program analysis intermediate statistics and waypoints are verified and stored on the FuzzLand chain, which can finally be leveraged to mint the auditing reports. + +Unlike traditional collaborative manual auditing platforms, FuzzLand uses sound automated program analysis (e.g., fuzzing and symbolic execution) techniques to provide accurate auditing reports. Since the program analysis results and intermediate waypoints can be easily verified through a fully automated oracle, the manual confirmation process is no longer needed. While it is impossible to quantify the performance of human auditors, FuzzLand can quantify the auditing progress and completeness of auditing reports based on metrics backed with on-chain data. + +The FuzzLand platform can offer two key benefits to the ecosystem. Firstly, it allows Substrate module and Ink developers to access low-cost, highly accurate auditing reports for their projects with on-chain guarantees. Secondly, the platform will be implemented as a Substrate chain and the platform's Substrate pallets can be easily reused by other projects. + +### Project Details + +#### Stakeholders + +* Project Owners: Anyone who needs an audit for their program. +* Validator Nodes (i.e., Judges): A proof of stake network that verifies the audting information. Note that these nodes are not necessary the validators of the *chain*. +* Auditor Nodes (i.e., Wardens): Anyone can run a nodes on their computers or even inside browsers to supply computation power for program analysis in return of token rewards. + +#### High Level Auditing Workflow + +``` ++---------+ +-------------+ +-------------+ +-------------------+ +-------+ +| Auditor | | Validator 1 | | Validator 2 | | Project Owner | | Chain | ++---------+ +-------------+ +-------------+ +-------------------+ +-------+ + | | | | | + | | | | 0. Onboard a project | + | | | |--------------------------------------------->| + | | | | | + | | | | 1. Ask for partition plan based on project | + | |<--------------------------------------------------------------------------------| + | | | | | + | | 1. Claim a partition plan and submit it | + | |-------------------------------------------------------------------------------->| + | | | | | + | | | 1. Challenge the partition plan if it is not correct | + | | |---------------------------------------------------------------->| + | | | | | + | | | | 2. Send the partition of the project | + |<---------------------------------------------------------------------------------------------------------------| + | -----------------------\ | | | | + |-| 2. Auditing with DPA | | | | | + | |----------------------| | | | | + | | | | | + | 3. When a testcase leading to vulnerability / new coverage found, submit the testcase | + |--------------------------------------------------------------------------------------------------------------->| + | | | | | + | | 3. Challenge the testcase if it is not correct | + | |-------------------------------------------------------------------------------->| + | | | | | + | | | | 4. Stop the auditing and mint the report | + | | | |--------------------------------------------->| + | | | | | + | | 4. Provide share of bounties based on the # of testcases submitted | + |<---------------------------------------------------------------------------------------------------------------| + | | | | | + | | | | 4. Provide share of bounties as reward | + | |<--------------------------------------------------------------------------------| + | | | | | +``` + + +0. Project owner can create an auditing request by staking tokens as bounties and providing the compiled program. + +1. The program being audited is divided into smaller subprograms of equal exploring complexity using static analysis by validator nodes. Each node is assigned a unique subprogram to audit for a specific period. This process, known as partitioning, is extremely fast and helps prevent auditor nodes from wasting computational power on code other nodes have already explored. The partitioning plan is deterministic and can be easily verified by other validator nodes, reaching consensus among all validator nodes before the auditing campaign begins. + +2. Each auditor nodes pick up a specific partition in the partitioning plan minted based on weighted sampling. Then, auditor nodes leverage fuzz testing techniques to analyze their subprogram. Auditor nodes are incentivized to prioritize auditing requests that are new, have high program complexity, and offer higher rewards. This is because auditor nodes are motivated to find more test cases that lead to vulnerabilities and new coverage, as well as to receive higher rewards for the test case NFTs they mint. + +3. When auditor nodes detect a test case leading to vulnerability or new code coverage, they mint an NFT for the test case. Judge nodes then verify the test case by re-executing it. Since the execution is deterministic, the outcome must also be deterministic, allowing validator nodes to reach consensus about the validity of test case NFTs. + +4. Project owner can terminate an audit request. The termination requests also mint an NFT for an auditing report automatically based on the intermediate statistics, test cases, and vulnerabilities. A reward (i.e., bounties) is then given to the validator nodes and auditor nodes that generated or verified the test case NFTs. + + +#### Technical Details + +**Partitioning Plan Synthesis** + +By converting a program into LLVM bytecode, we can create a weighted control flow graph (CFG) of it with the weight of each edge as relative difficulty of exploring such an edge. Graph partitioning algorithms can then partition the CFG into sub-trees, with the starting node of the CFG as the root of each tree. The partition plan can be concisely represented in O(log n) bytes, where `n` is the size of the CFG, making it possible to be fit into an on-chain variable. + +To determine the difficulty of exploring each edge in the CFG, we utilize static analysis tools. We pinpoint the comparison instruction that leads to the edge and determine the domain size of both the LHS and RHS. The domain size represents the likelihood of program execution failing into either side if the input is randomly selected. Currently, we use heuristics to determine the domain size. As future work, we can use abstract interpretation algorithms with a constraint solver to calculate it. The exploration difficulty is then estimated by dividing the domain size of the LHS and RHS. + +For instance, consider following simple program: + +```rust +// input: Vec +if (input[0] > 20) { // Line 1 + bug(); // Line 2 +} // Line 3 +``` + +The CFG would be +``` + + ┌──────────────┐ + ┌──────┤ Line 1 │ + │ └───────┬──────┘ + │ E2 │ E1 + │ ┌───────▼──────┐ + │ ┌──┤ Line 2 | + │ │ └──────────────┘ + │ │ E3 +┌──────▼───▼───┐ +│ Line 3 | +└──────────────┘ +``` + +Given `u8` domain is 256, weight (exploration difficulty) of E1 is `(256 - 20) / (256 + 20)` and E2 is `(256 + 20) / (256 - 20)`. By intuition, E2 is indeed more likely to be explored than E1. As there is no comparison instruction in during transition of E3, the exploration difficulty is 0, meaning as long as we can reach Line 2, we can reach Line 3. + +**Dynamic Program Analysis (DPA)** + +We support automated auditing of any program that can be compiled to LLVM bytecode by leveraging fuzz testing techniques, which involve sending random input to the program. This method, also known as heuristic search, aims to achieve 100% code coverage and uncover all vulnerabilities. While infinite time would guarantee zero false negatives, we use formal methods such as symbolic and concolic execution for guiding the fuzz testing search to reduce the time needed. Additionally, by partitioning the program into smaller, more manageable subprograms for each node, we can reduce the time required linearly as the number of nodes increases. + +Fuzz testing employs partitioning through the use of an instrumented target. If an input causes execution of code outside the partition plan, the target will terminate. Early termination reduces the time spent exploring code not within the partition, saving significant time. Similarly, symbolic and concolic execution can also conduct early-termination to avoid exploring code outside the partition. + + +**Reaching Consensus** + +Verifying partition plans and interesting test cases can be costly or even impossible on the chain. Thus, validator nodes use off-chain oracles. FuzzLand uses rollup techniques to move the oracle results onto the chain and reach consensus. Specifically, an optimistic rollup pallet is implemented to achieve consensus on partition plans and interesting test cases. Once a validator node mints a partition plan or an auditor node mints a test case NFT, other validator nodes can submit fraud proofs to challenge it within 50 blocks, or it will be committed. Unlike human auditors or judges, validator nodes can find evidence to challenge false claims in microseconds, as the verification process is automated and inexpensive, making optimistic rollups effective. + +*Interactively Partition Plan Verification*: Claimer can create a partition plan by submitting the weighted CFG and list of nodes in the CFG that needs to be divided. A challenger can either challenge the weighted CFG or the partition plan. To challenge the weighted CFG, the challenger submits a fraud-proof consisting of the root node of the minimum differing subtree in the CFG. The chain partially re-generates from that root node to the first child node by looking at branch, jump, and call instructions. That node must equal either party's differing node if at least one party is honest. Although generating full CFG is a costly operation as multiple complex graph analysis algorithm is needed, generating the next node with a known subgraph and context is cheap. To challenge the partition plan, the challenger must submit a better plan. The chain can compare the balance of each subgraph's total weights and determine which is the best partition plan. Comparison is very cheap since the chain only needs to sum up the weight of each subgraph and divide them. + +*Interactively Testcase Verification*: Claimer can confirm a test case by submitting the execution trace (a trace of basic blocks hit during execution) of the test case to the chain. The initial fraud-proof consists of the first differing program counter (PC) in execution trace and the state (i.e., dirty page of the memory and stack) before the differing PC. The challenged claimer can dispute the state and find the first differing state interactively with the challenger. When either the differing PC or state is found, the chain will re-execute partially from the state and PC with consensus (i.e., state and PC before the differing ones) using LLVM bytecode virtual machine. Since the execution would lead to a concrete result that is directly equal to that of either challenger or claimer, the chain can decide which party is gaming. Partial re-execution is not costly since the chain only needs to execute the basic block with dispute, which is usually a few simple instructions. A potential future work would be replacing this process with zero-knowledge proof. + +#### Technology Stack + +- Substrate +- Rust +- LLVM + +#### Dependencies + +- LibAFL for fuzzing +- Rustc for converting Substrate Pallets and ink! smart contracts to LLVM IR +- Substrate Client (https://github.com/scs/substrate-api-client) for WS communication between the chain and the oracles +- (Potentially) SymCC (https://github.com/eurecom-s3/symcc) for symbolic execution on LLVM bytecode +- (Potentially) yul2llvm (https://github.com/Veridise/yul2llvm) for converting Solidity to LLVM IR +- More TBD + +#### Implementation Details + +We are going to implement two Substrate modules with following traits: + + +**Optimistic Rollups**: +```rust +// Optimistic rollups pallet maintains a set of challengers and claimers. +// The claimers can claim arbitrary things that can be executed. +// The challengers can challenge arbitrary claims submitted previously. +// Optimistic rollups can transition costly on-chain execution to off-chain oracle while still reaching consensus with the execution correctness. +trait OptimisticRollups { + // When a challenge / dispute is submitted, use this function to determine whether the dispute is valid. + // Decision can be: wait for new argument (multi-round interactive rollups only); confirmed fraud; confirmed proof incorrect. + verifier: fn (proof: bytes) -> Decision; + + // When a claim is committed, the executor is invoked to execute the claim. + executor: fn (claim: bytes); + + // Claim something. + Claim(origin, data: bytes); + + // Challenge / Dispute a claim with proof. + Challenge(origin, proof: bytes); + + // Argue a challenge / dispute by challenger or claimer. + // Used for multi-round interactive rollups. + ArgueChallenge(origin, proof: bytes); + + // Commit latest block that may contain multiple claims. + Commit(origin); + + // Vote to ban a specific challenger / claimer. + // after an account gets enough vote, it gets removed from challenger / claimer set. + Ban(origin, account: Address); + + // Join with minimum token staked to be a challenger or claimer. + Join(origin, role: Role); +} + +``` + +Both partition plan and testcase can be interactively challenged and proved on chain efficiently by partial re-evaluation. + + +**Auditing**: +```rust +trait Audit { + // Onboard a project with minimum token (bounty) staked + // note: llvm_bytecode arg can be replaced by IPFS hash if the target is very large + OnboardProject(origin, llvm_bytecode: bytes) -> u256; + + // Offboard a project and mint a report + OffboardProject(origin, project_id: u256); + + // Submit a parition plan for the project by validator + SubmitPartitionPlan(origin, project_id: u256, plan: bytes); + + // Submit a testcase by auditor + SubmitTestcase(origin, project_id: u256, testcase: bytes); + + // Join with minimum token staked to be a validator or auditor + Join(origin, role: Role); + + // ...challenging methods +} +``` + +We are also going to implement the off-chain oracle. + +The oracle for auditor nodes needs to implement the DPA for LLVM targets that respect the partition they received. We use LLVM pass to modify the bytecode for achieving early termination and use LibAFL to manage the DPA campaign. + +LLVM Pass Pseudocode +```python +# Given Partition, Program +for BB in Program: + # Last instruction of BB is comparison instruction + if ProgramCounter(BB) not in Partition: + BB.Start.append( + new Instruction(Terminate()) + ) +``` + +The oracle for validator nodes needs to generate partition plans. We implement graph partitioning tool using Kernighan–Lin algorithm. As aforementioned, a crucial part for partitioning is the CFG edge weight calculation. We implement it using LLVM pass. + +Graph edge weight calculation Pseudocode +```python +# Given Program +for BB in Program: + # Last instruction of BB is comparison instruction + if BB.Tail is Comparison: + LHS, RHS, Op = BB.Tail as Comparison + # Count the percentage between domain of LHS and domain of RHS based on Op + return Count(Op, AbstractInterp(LHS), AbstractInterp(RHS)) + else: + return 0 +``` + +The oracle also interacts with chain by interacting with optimistic rollups. The VM used to re-execute LLVM bytecode partially is https://github.com/andoma/vmir, which can be compiled to WASM. We will implement a wrapper pallet for this VM. + +#### UI +Design Doc: https://xd.adobe.com/view/41cd2fa4-f124-4877-8b17-a8ff47799bf7-149e/ + +PoC Source Code: https://github.com/fuzzland/protocol_v1/tree/main/frontend + + +Screen 1: Onboarding - Upload Project +![](https://i.imgur.com/blNwnb7.png) + +Screen 2: Onboarding - Select Bounty +![](https://i.imgur.com/nJIFcWW.png) + +Screen 3: Auditing Report +![](https://i.imgur.com/2wX9Mf6.png) + + + +### Ecosystem Fit +Our platform can serve the project owners who have auditing requests for their projects, regardless of Web2 or Web3: as long as they can be compiled into LLVM (e.g., any Ink, Solidity, Rust, C++, etc. programs). The auditing reports and how they correlate with the on-chain statistics can also be reviewed by anyone: not just the project owner, but also the project users. Project owners can gain more trust by sharing the auditing reports backed with *consensus* with their users. + +Downstream DeFis, including insurance, using the auditing intermediate information and results can be deployed to our chain. As we enable the contracts pallet in our chain, the DeFis can be developed in the form of Ink smart contracts. XCM also makes it possible to pipeline the auditing results to other chains. + +Other projects can reuse the components of FuzzLand platforms. For example, the optimistic rollups pallet can be used by Layer 2 solutions. Collaborative manual auditing projects can also use the audit pallet or our chain by replacing the rollups pallet with consensus pallets. + +[Decentralized Security Marketplace](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/decentralized-security-marketplace.md) is a related RFP. [QRUCIAL DAO](https://github.com/w3f/Grants-Program/pull/989) is a related project in Substrate ecosystem. QRUCIAL DAO and FuzzLand both reach consensus about the auditing result. The fundamental differences are: +* FuzzLand harnesses the computation power of the crowd to perform compute-intensive dynamic program analysis, resulting in fast and highly accurate auditing. Yet, QRUCIAL DAO's analysis is performed by rerunning a same set of fast static analysis tools on multiple nodes, of which the requirement of multiple nodes is solely for reaching consensus. +* We support all LLVM targets, including Substrate pallet, ink!, Solidity, Move, Rust, C/C++, etc. projects while QRUCIAL DAO is tailored for smart contract auditing. +* We use optimistic rollups to efficiently reach consensus while QRUCIAL DAO uses the governance pallet. + +Code4rena, Immunefi, Secure3, Sherlock, etc. are similar projects in other ecosystems, but they all rely on human auditors. + +## Team :busts_in_silhouette: + +### Team members (In order of joining time) + +Jeff Liu (PM & Marketing) + +Chaofan Shou (Core Dev) - https://scf.so/ + +Shangying Tan (Core Dev) - https://shangyit.me/ + +Ben Fong (Core Dev + QA) + +Yiqi Hu (Core Dev) + + +### Contact + +- **Contact Name:** Jeff Liu +- **Contact Email:** jeff@fuzz.land +- **Website:** https://fuzz.land/ + +### Legal Structure + +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A + +### Team's experience + +Chaofan is a PhD student at UC Berkeley working on program analysis and distributed system. He has multiple research papers about fuzz testing in top conferences (e.g., [CorbFuzz](https://arxiv.org/pdf/2109.00398.pdf), [Rare Path Fuzzer](https://arxiv.org/pdf/2212.09004.pdf)). He has also participated in auditing and found numerous critical vulnerabilities in well-known software and Web3 protocols. He will work on the technical portion of the project, including implementing the aforementioned Substrate pallets and the offchain oracle. + +Shangyin is a PhD student at UC Berkeley working on formal methods and fuzzing. He has previously worked at Microsoft and contributed to well-known symbolic / concolic execution tools (e.g., [sai](https://github.com/Kraks/sai)). He will be developing the algorithm for partition plan synthesis and interactive verifiers in optimistic rollups. + +Yiqi Hu graduated with a master's degree from Carnegie Mellon University. She has a strong background in program analysis and will be working on implementing the fuzz testing algorithm. + +Ben graduated from SJSU and has a strong background in full-stack development and automated QA. He will be in charge of Web App development and CI/CD pipeline. + +Jeff is the founding engineer and PM at VMware Cloud Infra org and has founded multiple startups that have been acquired by companies like Alibaba. He has co-invested in well-known Web3 companies like Deeper Network, Holokit, etc. He will be overseeing the development process. + +### Team Code Repos + +- https://github.com/fuzzland/chain +- https://github.com/fuzzland/oracle + +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/shouc Chaofan Shou +- https://github.com/shangyint Shangying Tan +- https://github.com/benjaminfong Ben Fong +- https://github.com/YiqiHu Yiqi Hu + +### Team LinkedIn Profiles (if available) + + +## Development Status :open_book: + +- https://github.com/fuzzland/chain This is the Substrate chain implementation. We have just started to work on it. +- https://github.com/fuzzland/ityfuzz (Private for now, can share upon requests) This is our fuzz testing tool that can conduct DPA as described before. Supports for partitioning programs and conduct DPA on subprograms are WIP. Will be moved to `oracle` repo. +- https://github.com/fuzzland/protocol_v1 We have built a simple FuzzLand protocol PoC for EVM-compatible chain in Solidity. However, due to high gas fee, low throughput, and hard to customize the chain, we decide to switch to implement a Substrate chain. Frontend and telemetry API in this repo will be reused. +- https://github.com/AFLplusplus/LibAFL/pull/557 Adds the necessary analysis datasource for partition plan generation to the fuzzing library. +- https://dev.fuzz.land/ We also have the first version of our website. + + +#### Related Papers +* AFLTeam: https://ieeexplore.ieee.org/document/9678810/ +* LibAFL: https://dl.acm.org/doi/abs/10.1145/3548606.3560602 + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 5 months +- **Full-Time Equivalent (FTE):** 4 FTE +- **Total Costs:** 30,000 USD + +### Milestone 1 — Offchain Oracle + +- **Estimated duration:** 1.5 month +- **FTE:** 4 FTE +- **Costs:** 12,000 USD + +| Number | Deliverable | Specification | +| -----: | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of a validator or a auditor node. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article**/workshop that explains the technical details. We will also publish research papers about our algorithms and implementations. | +| 1. | Auditor Nodes Oracle Library | We will implement our DPA algorithm for LLVM targets in the form of a Rust library and fine tune it for ink! contracts and Substrate pallets. | +| 2. | Validator Nodes Oracle Library | We will implement the partition plan synthesis algorithm and offchain testcase validation tool in the form of a Rust library. | +| 3. | Verifier | We will develop the verifier for testcase validation and partition plan validation in the form of a Rust library that can be compiled to WASM. We will benchmark this library to ensure that the complexity of result verification is significantly lower than that of offchain oracles generating results. | +| 4. | Integration Testing | We will demonstrate that at least 3 auditor nodes oracle can efficiently collaborate to conduct program analysis for a ink! contract. We will also demonstrate that verifiers can be resistent to gaming by running a cluster of 2 honest validator nodes oracle and 1 malicious node. | + + +### Milestone 2 — Substrate Chain + +- **Estimated duration:** 3 month +- **FTE:** 4 FTE +- **Costs:** 18,000 USD + +| Number | Deliverable | Specification | +| -----: | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article**/workshop that explains the technical details and how to initiate an audit request. We will also publish research papers based on effectiveness of our solution and metrics collected from operating our platform. | +| 1. | Substrate module: optimistic_rollups | We will create a pallet that implements the optimistic rollups algorithm and a Rust SDK can that can interact with the pallet. We will also integrate the verifier developed in last milestone into this pallet. | +| 2. | Substrate module: audit | We will create a pallet for onboarding auditing requests, storing testcases, and distributing rewards. The pallet can also generate auditing reports in txt format automatically. | +| 3. | Substrate chain | Module `optimistic_rollups` and `auditing` will be integrated into a Substrate node, to enable auditor nodes to submit intermediate auditing results and information. This chain will integrate contracts, treasury, council, democracy and also other essential pallets, to build a full-featured blockchain. | +| 4. | Offchain oracle clients | Auditor and validator nodes clients will be built by integrating the libraries built in the last milestone. The two clients will be able to interact with the chain so that the full auditing workflow shown in the [Project Details](#Project-Details) can be accomplished. | +| 4. | Web App | We will create a web app, to let users easily interact with our substrate node. Users can create auditing requests, visualize intermediate auditing information, and view final auditing report. | + +## Future Plans + +* Allowing project owners to define their own types of vulnerabilities (e.g., business logic violations). +* Bring in ZK-SNARKs for testcase sharing. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Personal recommendation diff --git a/applications/Gafi.md b/applications/Gafi.md index 4faea88d22a..af936c5e7c6 100644 --- a/applications/Gafi.md +++ b/applications/Gafi.md @@ -1,8 +1,7 @@ -# W3F Grant Proposal +# Gafi Network - The Network of Game Finance - -- **Project Name:** Gafi Network - The Network of Game Finance - **Team Name:** Cryptoviet +- **Gafi Paper:** https://gafi.network/GafiPaper.pdf - **Wiki:** https://wiki.gafi.network/ - **Payment Address:** 0x7fD4b72d3Bf681C2e80D6076D7997B21DEf45130 (USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 @@ -160,7 +159,7 @@ Stefan with 5 years of experience as Software Engineer working on the top crypto ## Development Status :open_book: -Gafi Node Repos: https://github.com/cryptoviet/gafi +Gafi Node Repos: https://github.com/grindytech/gafi [Heroes & Empires 2021 Roundup](https://medium.com/@stefan_muto/heroes-and-empires-2021-roundup-a6617941ef5a) @@ -175,7 +174,7 @@ Whitepaper: Coming soon - **Total Estimated Duration:** 11.5 months - **Full-Time Equivalent (FTE):** 1.2 FTEs -- **Total Costs:** 59,000 USDT +- **Total Costs:** 52,700 USDT ### Milestone 1 — The Heroes & Empires @@ -244,11 +243,10 @@ In this milestone, the requirements will fall into acceptance criteria: - **Estimated duration:** 4 months - **FTE:** 1.2 -- **Costs:** 19,000 USD +- **Costs:** 12,700 USD In this milestone, the requirements will fall into acceptance criteria: + Gafi Network Testnet launch with at least 5 nodes -+ Build DAO to vote on-chain governance + Pallet Game-Creator works + Determine the 'x' number of limit discount transactions per minute by Testnet and vote by on-chain governance + Determine the 'y' percentage to reduce transaction fee by Testnet and vote by on-chain governance @@ -266,9 +264,8 @@ In this milestone, the requirements will fall into acceptance criteria: | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | 0e. | Article | wiki.gafi.network and Medium | | 1. | Substrate module: pallet game-creator | https://wiki.gafi.network/learn/game-creator | -| 2. | Substrate module: pallet_dao | module to vote on-chain runtime data | -| 3. | Weights/Benchmarking | implement benchmarking for pallets to determine appropriate weights | -| 4. | Demo | Demo new features in milestone 3 with guide article | +| 2. | Weights/Benchmarking | implement benchmarking for pallets to determine appropriate weights | +| 3. | Demo | Demo new features in milestone 3 with guide article | ## Future Plans diff --git a/applications/GenesisDAO.md b/applications/GenesisDAO.md new file mode 100644 index 00000000000..83747d3c07b --- /dev/null +++ b/applications/GenesisDAO.md @@ -0,0 +1,210 @@ +# GenesisDAO + +- **Team Name:** GenesisDAO by Deep Ink Ventures GmbH +- **Payment Address:** Ethereum Mainnet, 0x918a4363C35156c8F85F86795a79189e5A1ef557, USDC +- **Level:** 3 + +## Overview + +### Intro +Historically, building DAOs requires heavy commitments to a specific chain and development of features on top of skeleton frameworks or template builders +such as OpenZepplin governance or Aragon DAO. + +This in turn led to significant costs occurring in development, legal structure and voting mechanisms. As of today, launching a DAO alongside your crypto project remains a mission. + +We see XCM as a shift in the way blockchains interoperate. 10+ years after Forbes announced the API revolution for the Client-Server Architecture of Web 2.0; crosschain messaging is setup to move blockchains into platforms that can abstract away its complexities and specializations behind a sharp +interface that protocols on other chain-ecosystems can utilize by tapping into its XCM specifications. + +Genesis DAO is among this new wave of emerging platforms and provides DAOs as a Service. + +Having this in the polkadot ecosystem is not only a huge benefit for existing parachains and protocols, itll be a competitive advantage for +the polkadot ecosystem as one of the first questions projects have to face nowadays is: Where to launch the DAO? On Genesis DAO. + +### Abstract +Genesis DAO is a platform as a service for DAOs. The platform lives on a polkadot parachain and utilizes Cross Consensus Messages (XCM) as a first-class citizen of its infrastructure. + +It allows teleporting of DAO tokens to other chains to be native parts of the protocol while voting, treasury and other DAO infrastructure is living natively on Genesis DAO. Genesis DAO manages the ramifications of DAO on its robust platform – the DAO token itself becomes a lego block that can live on every chain of choice. + +### Conceptual Overview +EVMs ERC-20 token is a shining example of the Unix philosophy of doing one thing and doing it right: The entire DeFi stack was +built on the shoulders of simple transfer and transferFrom methods alongside a balance entry for bookkeeping. + +The basic layer of Genesis DAO is of similar structure, it has the main primitives of DAO participants baked in - voting. This token +and its defined interface can live on all chains and can communicate back to the Genesis DAO infrastructure layer. The DAO Token +is detangled from both - the complications of the DAO governance layer and the wiring to the protocol that it governs. +The parachain infrastructure builds on top of this layer and adds composable features on top of it. + +The governance layer and the central infrastructure become first class (pallet level) citizens of the genesis DAO chain and the +feature structure and runtime updates are subject to the votes of Genesis DAO Token Holders themself. + +Therefore the basic primitives of a DAO to manage its votes, treasury and token distribution will be a fundamental building block of the chain itself. + +On top of this lays an EVM (Solidity) and WASM (e.g. Ink!) Layer for protocols to support further customization such as legal structure +document storage and setup, yield aggregation protocols and so on. + +![image](https://user-images.githubusercontent.com/120174523/206688325-d5509f7c-00ff-4e90-9545-0588e3486ff1.png) + +Since these protocols have a joint understanding of the interfaces within, Genesis DAO will be a parachain specialized in DAOs. + +Home of the governance for everything on chain, with its token becoming a lego block in the ecosystem of all blockchains that aim for decentralized governance. + + +## Project Details + +### Architectural Overview + +The basic idea of GenesisDAO is the separation of concerns between the operational layer of a protocol and the governance layer of a protocol: The DAO itself is conceptually separated from the implementation of the business processes, but this separation is abstracted away from the user by utilizing XCM. + +Therefore there are three ways to interact with GenesisDAO: DAO Operations, Proposal Creation and Voting. + +
          + +*DAO Operations* is the process of creating a DAO, minting the initial token, treasury management and so on. In development terms, this will be a UI on top of the Genesis DAO itself, the creation and management will have a dedicated pallet and we want to build customization hooks that introduce ink! as a configuration language. The substrate implementation section below will elaborate on this. + +*Proposal Creation* is a an orchestrated process of creating a proposal in the UI with metadata, description, documentation, binary files like images and so on; packaging all of that data in a structured format and upload it to IPFS and then commit the IPFS hash alongside with metadata and proposal lifecycle information to the Genesis DAO chain. + +
          + +The voting process will happen asynchronously, so users on remote chains can vote as well. Voting is the signaling of approval or denial to a proposal and it can be done from remote chains. + +This requires some heavy XCM lifting and some custom extensions to ink! and EVM token implementations, but from the perspective of the user they will be able to participate in governance voting without being aware of the underlying complexities by calling simple *vote(proposalId, approve)* methods on their tokens. + +
          + + +### Substrate Implementation + +Genesis DAO is constructed of multiple pallets that separate the concerns of a DAO. Due to its XCM-first approach, it has infrastructure build on top of itself and an integration pallet for other parachains. + +The following architecture describes the state before parachain launch, the scope of this first iteration is described in the Development Roadmap section of this document. + +![image](https://user-images.githubusercontent.com/120174523/207329991-0d86a47f-3951-428d-bc0a-4647d603f074.png) + +The heart of the chain is the *pallet_dao_core* that offers functionality to create a DAO and store metadata components. +It manages the entire lifecycle of a DAO from creation, token issuance, management and so on. + +Tokens itself are created via a custom asset pallet: *pallet_dao_asset* that is a fork from *pallet_asset*, but with +checkpoint writing upon transfer. This idea is inspired by the compound protocol, where the current voting power at any +given block is stored on chain as well. Consequently, voters can signal approval or rejection of a proposal at any time +during the proposal lifecyle, but the actual voting power is determined on closing of the proposal. This technique ensures +that the token can really live and be traded on other chains, as no lockup on the GenesisDAO chain is required. + +The *pallet_dao_vote* is managing proposal lifecycle, where new proposals for a DAO can be made. + +The *pallet_dao_xcm* is managing the interface of the GenesisDAO chain to other parachains. It'll expose the functionality +of transferring a token to other chains and the ability to report votings and token transfers back. Votings will be +forwarded to the *pallet_dao_vote* to register approval or rejection whereas token transfers are forwarded to the *pallet_dao_asset* +to write a checkpoint. This pallet is accompanied by a *pallet_dao_integration* that other chains can add in order to integrate +the GenesisDAO into their chain. Since this functionality is of elevated interest for protocol-enabling chains with EVM or +ink! support, we will accompany these with our own standard, ERC20DAO, that is the traditional ERC20 interface with additional +voting methods within the interface and support for the transfer-function XCM extension that enables checkpoint writing on the Genesis DAO. + +The GenesisDAO is a protocol enabling chain as well and all pallets on the chain will offer hook functionality into ink! +(and later EVM) based contracts. Those hookpoints (contract addresses) are stored in the DAO metadata in *pallet_dao_core* +and give DAOs (or third parties building on top of GenesisDAO) the opportunity to plug-in central mechanisms of the DAO such +as voting-calculations, checkpoint creation, vesting and so on. All pallets will utilize *pallet_contracts* call function to +interact with sharp interfaces, making GenesisDAO a true, extendable platform for complex and custom DAO setups. + + + +## Ecosystem Fit + +Standing on the shoulder of giants is the driving force of success in tech. Each development software is +build on uncountable prior engineering power. It's as well a crucial factor of success and adoption of +a decentralized network and the strength of polkadot lies in the interoperability with other chains. + +Given the importance of robust, scalable and customizable DAO infrastructure, we want to establish GenesisDAO +as a common good parachain within the ecosystem. Easy-to-use, open source, reliable and future proof DAO management +is a crucial element in decentralization and having DAO infrastructure as a first class citizen in the polkadot +ecosystem will drive adoption to the network. + + +## Team + +### Contact + +- **Contact Name:** Jakob Drzazga +- **Contact Email:** jad@deep-ink.ventures + +### Legal Structure + +- Deep Ink Ventures GmbH, registered with the commercial register at the local court of Berlin, HRB 247342 + +## Development Roadmap + +### Overview + +- **Total Estimated Duration:** 3 month +- **Full-Time Equivalent (FTE):** 3-4 FTE +- **Total Costs:** $ 100,000 + +### Milestone 1 Substrate Node, Dao Core, Frontend Setup and Product Initiation + +- **Estimated duration:** 1 month +- **FTE:** 3-4 +- **Costs:** 40,000 + +| Number | Deliverable | Specification | +| -----: |-----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will add a functional test suite that covers the user flows and a manual test guide. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Parachain Setup | We will provide a docker-compose setup to spin up the entire system easily in a local environment | +| 2. | Substrate module: pallet_dao_core | We will create the dao core module that allows creating a dao, issue a token (intially based on *pallet_assets*) and manage metadata and the dao lifecycle. | +| 3. | Frontend Infrastructure | We will setup and host a react/typescript/next.js application that will serve as dApp for our GensisDAO. | +| 4. | Design and Product Flow | We will create UI/UX flows and designs for the dao creation process. | + + +### Milestone 2 Proposal module, Asset fine tuning, No-Code DAO creation and proposal UX flow + +- **Estimated Duration:** 1 month +- **FTE:** 3-4 +- **Costs:** 40,000 USD + + +| Number | Deliverable | Specification | +| -----: |------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will add a functional test suite that covers the user flows and a manual test guide. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Substrate module: pallet_dao_asset | We will fork the pallet_asset and customize it for DAO optimization needs, most prominently with checkpoint functionality. | +| 2. | Substrate module: pallet_dao_vote | We will create a voting module to manage the lifecycle of a proposal | +| 3. | Frontend Implementation | We will implement the frontend and UX flows developed in the previous milestone product section and have a no-code DAO creation experience | +| 4. | Design and Product Flow | We will create UI/UX flows and designs for the dao proposal process. | + +### Milestone 3 Proposal module, Asset fine tuning, No-Code DAO creation and proposal UX flow + +- **Estimated Duration:** 1 month +- **FTE:** 2-3 +- **Costs:** 20,000 USD + + +| Number | Deliverable | Specification | +| -----: |------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. We will add a functional test suite that covers the user flows and a manual test guide. | +| **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** introducing GensisDAO, it's core concepts and vision to the public | +| 1. | Substrate module: pallet_dao_vote | We will create a voting module to manage the lifecycle of a proposal | +| 2. | Frontend Implementation | We will implement the frontend and UX flows developed for the proposal and have a voting process directly on GenesisDAO (usable without xcm) and a no-code proposal integration. | +| 3. | Product Touches | We will create a full product experience around the dApp with landing pages, FAQ, and explainers. | 4. | Benchmark Support | We will provide basic benchmarking modules for our pallets. | + + +## Future Plans + +After finishing this grant, GensisDAO will be able to manage DAOs and proposal processes within it's own substrate based blockchain. + +The next two important steps will be + +- the implementation of the XCM layer, which in turn requires upgrading the chain to parachain-readyness +- the addon of the contracts pallet alongside with hookpoints and there integration into the existing pallets + +Simoultanously, we will start building initial ink! infrastructure. Since we are heavily committed to shiny and +elegant UX and UI, we want to heavily invest into user research and rapid feedback cycles to incorporate the needs of the +community directly after the PoC that is build within this grant is live. + +The important outline for this project is to become a common good parachain, that acts as an infrastructure service for the ecosystem. Therefore extendable integrations with other important chains in the polkadot realm as well as attracting dao-specific protocols to extend the base chain functionality is part of the near term roadmap as well. + diff --git a/applications/Gluon_decentralized_hardware_crypto_wallet_services.md b/applications/Gluon_decentralized_hardware_crypto_wallet_services.md index 5ceeb82808e..0657d4ab785 100644 --- a/applications/Gluon_decentralized_hardware_crypto_wallet_services.md +++ b/applications/Gluon_decentralized_hardware_crypto_wallet_services.md @@ -1,54 +1,57 @@ -# Open Grant Proposal +# Gluon - Decentralized Hardware Crypto Wallet Services > This document is referenced in the terms and conditions and therefore needs to contain all the required information. Don't remove any of the mandatory parts presented in bold letters or as headlines! See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/blob/master/README_2.md) on how to submit a proposal. -* **Project Name:** Gluon - Decentralized Hardware Crypto Wallet Services * **Team Name:** TEA Project * **Payment Address:** ERC20(DAI etc.):0x0cE6254832D553590349Ef7a427519d1eb8af70F +* **Status:** [Cancelled]( +https://github.com/w3f/Grants-Program/pull/182#issuecomment-1571885497) > *The above combination of your GitHub account submitting the application and payment address will be your unique identifier during the program. Please keep them safe.* -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: + > If this application is in response to an RFP, please indicate this on the first line of this section. ### Overview -Leaking or losing private keys are the primary concerns of most blockchain users. Gluon uses a new approach to prevent such issues. +Leaking or losing private keys are the primary concerns of most blockchain users. Gluon uses a new approach to prevent such issues. -Gluon is a TaaS (Trust-as-a-Service) application that provides hardware crypto wallet services to crypto users. Our main goal is to create an all-in-one private key manager for Polkadot ecosystem blockchains. +Gluon is a TaaS (Trust-as-a-Service) application that provides hardware crypto wallet services to crypto users. Our main goal is to create an all-in-one private key manager for Polkadot ecosystem blockchains. Features: -- Passwordless. Users won't have to take responsibility for backup mnemonic phrases. Social recovery is available for users who have lost all their authentication devices. -- Gluon manages Schnorr Multisig Keys that are randomly distributed and encrypted by hardware-secure-modules (HSM). We call them TEA nodes. -- Users only need to submit a transaction to Gluon, and it will take over the signing and committing to blockchains. -- Leverages popular biometric technologies in mobile devices to attain better user experiences without compromising security. +* Passwordless. Users won't have to take responsibility for backup mnemonic phrases. Social recovery is available for users who have lost all their authentication devices. +* Gluon manages Schnorr Multisig Keys that are randomly distributed and encrypted by hardware-secure-modules (HSM). We call them TEA nodes. +* Users only need to submit a transaction to Gluon, and it will take over the signing and committing to blockchains. +* Leverages popular biometric technologies in mobile devices to attain better user experiences without compromising security. -Gluon is built into a WebAssembly module loaded and ran inside the T-rust framework (they are both TEA projects). Gluon is an application (we call TeaLeaf); T-rust is a framework (TeaTree). T-rust contains layer1 and layer2; Layer1 is a blockchain built using Substrate, while Layer2 is an exceptionally designed mini OS along with WebAssembly modules that run on wasm runtime powered by [WaSCC](https://wascc.dev). Gluon also contains layer1 and layer2. Layer1 is a Substrate pellet running inside Tea Layer1 blockchain, and layer2 is a set of WebAssembly actors running in every TEA node's TeaRuntime. +Gluon is built into a WebAssembly module loaded and ran inside the T-rust framework (they are both TEA projects). Gluon is an application (we call TeaLeaf); T-rust is a framework (TeaTree). T-rust contains layer1 and layer2; Layer1 is a blockchain built using Substrate, while Layer2 is an exceptionally designed mini OS along with WebAssembly modules that run on wasm runtime powered by [WaSCC](https://wascc.dev). Gluon also contains layer1 and layer2. Layer1 is a Substrate pellet running inside Tea Layer1 blockchain, and layer2 is a set of WebAssembly actors running in every TEA node's TeaRuntime. -Gluon serves all Polkadot ecosystem dApps and other blockchains as an entry point (portal); it is transparent to other client chains. There is no integration needed. +Gluon serves all Polkadot ecosystem dApps and other blockchains as an entry point (portal); it is transparent to other client chains. There is no integration needed. We designed and developed Gluon to: -- Lower the barrier to blockchain end-users; improve user experiences. -- Protect users' crypto assets. -- Demonstrate the potential of the Substrate framework and TEA project. +* Lower the barrier to blockchain end-users; improve user experiences. +* Protect users' crypto assets. +* Demonstrate the potential of the Substrate framework and TEA project. >Please provide the following: -> * A brief description of the project. -> * An indication of how you will integrate this project into Substrate / Polkadot / Kusama. -> * An indication of why your team is interested in creating this project. +> +> * A brief description of the project. +> * An indication of how you will integrate this project into Substrate / Polkadot / Kusama. +> * An indication of why your team is interested in creating this project. -### Project Details +### Project Details #### Unique features of Gluon From a users point of view, Gluon works just like a hardware wallet, but with a few differences: -- A traditional hardware wallet is just one single hardware secure module (HSM), but Gluon is a group of potentially thousands of HSM running consensus together to protect clients' assets. (Every TEA Mining Node is an HSM which can be considered as a hardware wallet) -- Users need both a Polkadot extension and a Gluon mobile app to access their Gluon account as 2FA. -- Users can transfer authentication factors from one device to another without backing up and restoring mnemonic phases. -- If users lose both their computer (web auth) and phone (mobile auth), social recovery can still protect and recover their new accounts' crypto assets. -- Users only need to submit a transaction then Gluon will submit the signature to the client blockchain without further user interaction. +* A traditional hardware wallet is just one single hardware secure module (HSM), but Gluon is a group of potentially thousands of HSM running consensus together to protect clients' assets. (Every TEA Mining Node is an HSM which can be considered as a hardware wallet) +* Users need both a Polkadot extension and a Gluon mobile app to access their Gluon account as 2FA. +* Users can transfer authentication factors from one device to another without backing up and restoring mnemonic phases. +* If users lose both their computer (web auth) and phone (mobile auth), social recovery can still protect and recover their new accounts' crypto assets. +* Users only need to submit a transaction then Gluon will submit the signature to the client blockchain without further user interaction. #### Key distribution and protection @@ -56,49 +59,50 @@ From a users point of view, Gluon works just like a hardware wallet, but with a Gluon generates Polkadot accounts for users using the 2-out-of-3 Schnorr Threshold Multsig Algorithm implemented by Schnorrkel. The account public key is aggregated from the 3 key pairs while the private keys are kept by 3 individual parties. They are called P1, P2, and P3. -Among them, P1 is a single sign key stored in the users' mobile phones. Both P2 and P3 are Schnorr multisig keys. Gluon owns P2 for additional security policy control, while Guardians (assigned by the User) owns P3. +Among them, P1 is a single sign key stored in the users' mobile phones. Both P2 and P3 are Schnorr multisig keys. Gluon owns P2 for additional security policy control, while Guardians (assigned by the User) owns P3. P2 is a Schnorr threshold multisig key, which means instead of a single signer, a group of signers control P2. For example, we call them key-pieces such as P2-1, P2-2, P2-3, and so on. They are separately generated and stored by different TEA nodes. Multiple TEA nodes distribute the private key of each signer as the replica. We do not allow a single TEA node to hold more than one key piece of any P2 to prevent any TEA node has enough key-pieces to reach the multisig threshold. This policy also guarantees better distribution of key-pieces over TEA nodes. The signature algorithm is implemented by Schnorrkel too. -P3 is also a Schnorr threshold multisig key but each key-pieces owned by different guardians. Users need to assign their friends or legal entities as guardians. K of n guardians could sign the social recovery transaction to restore a user's account if it lost its P1. This process is called [Social Recovery](https://www.parity.io/social-recovery-on-substrate/). +P3 is also a Schnorr threshold multisig key but each key-pieces owned by different guardians. Users need to assign their friends or legal entities as guardians. K of n guardians could sign the social recovery transaction to restore a user's account if it lost its P1. This process is called [Social Recovery](https://www.parity.io/social-recovery-on-substrate/). -P1 is stored in the users' Gluon mobile app. P1 will never be exposed beyond the phone, even when upgrading devices. However, Gluon doesn't require users to take responsibility to backup mnemonic phrases. When upgrading to a new phone, the Gluon app can transfer P1 securely to the new device without exposing it to the network. If users lose their phones, there is no way to restore P1 because there are no backup mnemonic phrases. Lost or being hacked of P1 does not lead to a loss of assets, as one can use P2+P3 for recovery, and bad actors would need two keys to access crypto assets in the case of a leak. As mentioned above, Gluon can transfer all assets to one's new account by running a social recovery process. +P1 is stored in the users' Gluon mobile app. P1 will never be exposed beyond the phone, even when upgrading devices. However, Gluon doesn't require users to take responsibility to backup mnemonic phrases. When upgrading to a new phone, the Gluon app can transfer P1 securely to the new device without exposing it to the network. If users lose their phones, there is no way to restore P1 because there are no backup mnemonic phrases. Lost or being hacked of P1 does not lead to a loss of assets, as one can use P2+P3 for recovery, and bad actors would need two keys to access crypto assets in the case of a leak. As mentioned above, Gluon can transfer all assets to one's new account by running a social recovery process. #### Hardware Secure Module -TEA nodes are HSM (Hardware Secure Module). One can consider commonly used hardware wallets as special-purpose HSM, but TEA nodes are a general-purpose HSM that can do much more. The secret will never be exposed outside of hardware-protected TEA node's RAM nor saved to any storage media persistently. When transferring secrets between TEA nodes (for example, distributing replica), every TEA nodes will run Remote Attestation before an end to end encryption and send. When using P2 co-signing a transaction, the TEA Node will query the layer1 blockchain to verify the signing conditions first and then sign the transaction inside HSM. No secret leaves the HSM except the digital signature. Each co-signer sign using its holding key-piece to a signature-piece. These signature-pieces get aggregated in layer-1 blockchain to become a single signature. As long as the number of co-signers reaches the threshold, this signature can pass verification by Polkadot. +TEA nodes are HSM (Hardware Secure Module). One can consider commonly used hardware wallets as special-purpose HSM, but TEA nodes are a general-purpose HSM that can do much more. The secret will never be exposed outside of hardware-protected TEA node's RAM nor saved to any storage media persistently. When transferring secrets between TEA nodes (for example, distributing replica), every TEA nodes will run Remote Attestation before an end to end encryption and send. When using P2 co-signing a transaction, the TEA Node will query the layer1 blockchain to verify the signing conditions first and then sign the transaction inside HSM. No secret leaves the HSM except the digital signature. Each co-signer sign using its holding key-piece to a signature-piece. These signature-pieces get aggregated in layer-1 blockchain to become a single signature. As long as the number of co-signers reaches the threshold, this signature can pass verification by Polkadot. #### Access control logic -Polkadot allows unlocking User's DOT based on 2 of 3 mutisig from P1 P2 and P3. Gluon has no control over P1 (owned by the User) and P3 (owned by the User's friend - guardians). If a user no longer trusts Gluon, it can ask its guardians to sign P3 along with its P1, and the User still has full control over its assets. If a user lost its P1, it could create a new P1 then recover its assets by running the social recovery process by P2 and P3. If a user wants to update its guardians' list, it can create a new P3 since P1 and P2 are available. +Polkadot allows unlocking User's DOT based on 2 of 3 mutisig from P1 P2 and P3. Gluon has no control over P1 (owned by the User) and P3 (owned by the User's friend - guardians). If a user no longer trusts Gluon, it can ask its guardians to sign P3 along with its P1, and the User still has full control over its assets. If a user lost its P1, it could create a new P1 then recover its assets by running the social recovery process by P2 and P3. If a user wants to update its guardians' list, it can create a new P3 since P1 and P2 are available. P1 is stored in users' mobile apps. Gluon mobile app uses general mobile security protections to protect P1. Such as Biometric ID, Symmetric encryption (6 digits user input passcode), Hardware security chip for some particular model when available. P1 along won't be more secure than other modern crypto wallet mobile apps. That's why we have additional P2 and P3 to protect the User's crypto assets. -P2 is the only key owned by Gluon. When a user requests to sign a transaction, each TEA node that holds a key-piece will run authentication logic separately. The authentication logic includes +P2 is the only key owned by Gluon. When a user requests to sign a transaction, each TEA node that holds a key-piece will run authentication logic separately. The authentication logic includes -- Verifying web and mobile 2FA. The User has to submit a signing request using both the Polkadot browser extension and Gluon mobile app. -- For spending transactions, verify the daily limit or other constraints set by the User in layer1. For example, when the User claims loss of P1 and sets its assets in the Social Recovery frozen period, Gluon will suspend the request. -- For social recovery transactions, verify the guardians' signature follow the predefined logic. For example, suppose a user lost both their computer and mobile phone (all 2FA). In that case, additional requirements apply to social recovery processes such as time window, sequence, or geolocation to mitigate phishing attacks. +* Verifying web and mobile 2FA. The User has to submit a signing request using both the Polkadot browser extension and Gluon mobile app. +* For spending transactions, verify the daily limit or other constraints set by the User in layer1. For example, when the User claims loss of P1 and sets its assets in the Social Recovery frozen period, Gluon will suspend the request. +* For social recovery transactions, verify the guardians' signature follow the predefined logic. For example, suppose a user lost both their computer and mobile phone (all 2FA). In that case, additional requirements apply to social recovery processes such as time window, sequence, or geolocation to mitigate phishing attacks. -Given such logic run on the Gluon Pellet (on-chain) and Gluon Wasm Actors (off-chain), in the future, we can easily add more complex logic without on-chain limitations. +Given such logic run on the Gluon Pellet (on-chain) and Gluon Wasm Actors (off-chain), in the future, we can easily add more complex logic without on-chain limitations. -P3 is only used for Social Recovery. Because of Schnorr Mutisig Algorithm, the guardians' list never exposes in the clear on the blockchain. Even the guardians themself won't know they are selected guardians or know other guardians in the same group. There is little chance for guardians to collude and sign P3 without the User's permission. +P3 is only used for Social Recovery. Because of Schnorr Mutisig Algorithm, the guardians' list never exposes in the clear on the blockchain. Even the guardians themself won't know they are selected guardians or know other guardians in the same group. There is little chance for guardians to collude and sign P3 without the User's permission. #### User experiences -From the end user's point of view, Gluon is a mobile app and a web extension. The end-user needs to install the Polkadot web extension on their browser to visit any dApp sites to generate transactions to be signed. They also will need to install a Gluon mobile app as a decentralized 2FA (not the traditional centralized 2FA). +From the end user's point of view, Gluon is a mobile app and a web extension. The end-user needs to install the Polkadot web extension on their browser to visit any dApp sites to generate transactions to be signed. They also will need to install a Gluon mobile app as a decentralized 2FA (not the traditional centralized 2FA). -Users can go to the Gluonwallet.com website or any other compatible dApp to create a transaction. The web extension will generate a transaction like a QR code on the web page. Users will use the Gluon mobile app to scan this QR code, verify the transaction details, then fingerprint-unlock the partial signing on the phone. Once the phone sends the partial signature to the Gluon network, TEA nodes will multisign the same tx using P2. Once two partial signatures are complete, they are aggregated and committed to the client blockchain to continue processing the transaction. +Users can go to the Gluonwallet.com website or any other compatible dApp to create a transaction. The web extension will generate a transaction like a QR code on the web page. Users will use the Gluon mobile app to scan this QR code, verify the transaction details, then fingerprint-unlock the partial signing on the phone. Once the phone sends the partial signature to the Gluon network, TEA nodes will multisign the same tx using P2. Once two partial signatures are complete, they are aggregated and committed to the client blockchain to continue processing the transaction. #### Relationship between Gluon and T-rust -From the miners' point of view, Gluon is a dApp that runs on top of the T-rust framework. When compiling the source code, a WebAssembly file "gluon.wasm" is generated. This wasm file is loaded to the miner's TEA node by adding Gluon.wasm file hash to their TEA nodes' manifest file. Miners can load this wasm module from IPFS directly. Once "gluon.wasm" is loaded into TEA runtime, this TEA node becomes a TEA hardware wallet capability provider. +From the miners' point of view, Gluon is a dApp that runs on top of the T-rust framework. When compiling the source code, a WebAssembly file "gluon.wasm" is generated. This wasm file is loaded to the miner's TEA node by adding Gluon.wasm file hash to their TEA nodes' manifest file. Miners can load this wasm module from IPFS directly. Once "gluon.wasm" is loaded into TEA runtime, this TEA node becomes a TEA hardware wallet capability provider. Gluon.wasm only handles crypto wallet related logic. All other consensuses, security, network, and hardware validation happens in the T-rust framework. ![relationship tea](https://cdn-images-1.medium.com/max/1120/1*2O7WDwTwH4DlIr4zbOMxng.png) #### Gluon and T-rust's root of trust and PoT (Proof of Trust) consensus + T-rust is a layer2 trusted computing solution on top of a Substrate-based blockchain (layer1). Unlike most blockchain, whose root-of-trust comes from cryptography and consensus, T-rust introduces hardware root-of-trust as the third dimension. Unlike most other blockchains that make consensus on the result, T-rust makes consensus on the proof of trust that comes from hardware TPM chips. Using hardware RoT makes the consensus much more efficient than many blockchains. T-rust can run complex or privacy-sensitive computations, which are not likely possible in other blockchains. Distributed storage of private keys needs both privacy and complex computing, so Gluon is an ideal dApp running on top of T-rust. Gluon and T-rust are two TEA Projects. ![root of trust](https://cdn-images-1.medium.com/max/1120/1*5cLoCE4mLRw7hhDjcuaAxA.png) @@ -108,23 +112,22 @@ T-rust is a layer2 trusted computing solution on top of a Substrate-based blockc There is nothing that needs to be done for other blockchains when integrating with Gluon as long as the client blockchain supports Schnorr Multisig. Gluon is transparent to other client blockchains. Gluon is virtually a client who commits the signed transaction and listens to block events. Polkadot will support off-line Schnorr Multisig very soon. For other dApps, integrating with Gluon is as simple as adding one js API. This js API does three things: -- Gathering input transaction details and show in a QR code. Prompt the User to scan this QR code using Gluon mobile app. -- Sending the hash of transaction and client_id in a TEA transaction to the TEA blockchain. - +* Gathering input transaction details and show in a QR code. Prompt the User to scan this QR code using Gluon mobile app. +* Sending the hash of transaction and client_id in a TEA transaction to the TEA blockchain. #### UI mockups ![typical workflow](https://github.com/tearust/gluon-docs/blob/master/res/typical-workflow.png?raw=true) -The diagram above shows a typical UI workflow, which is signing a DOT spending transaction. +The diagram above shows a typical UI workflow, which is signing a DOT spending transaction. -Users start a task from the web browser. It could be the Gluon web portal or any dApps' website embedded with our js API. A hash of the transaction detail is sent to Gluon TeaLeaf. A QR code is shown on the web page for the paired Gluon mobile app to scan. +Users start a task from the web browser. It could be the Gluon web portal or any dApps' website embedded with our js API. A hash of the transaction detail is sent to Gluon TeaLeaf. A QR code is shown on the web page for the paired Gluon mobile app to scan. After scanning the QR code, the Gluon mobile app shows the transaction's detail for users to confirm visually. Users approve this transaction by fingerprinting and six digits wallet passcode. Gluon mobile app partially signs the transaction using P1. Both the signature and transaction details are sent to Gluon TeaLeaf to continue. -Gluon TeaLeaf takes over the rest of the task by verifying and signing using P2. Finally, Gluon TeaLeaf sends the signature by P1 and P2 to Polkadot to complete the transaction. +Gluon TeaLeaf takes over the rest of the task by verifying and signing using P2. Finally, Gluon TeaLeaf sends the signature by P1 and P2 to Polkadot to complete the transaction. The User will receive the confirmation event of a completed task. @@ -137,20 +140,20 @@ T-rust is a bit more complicated. ##### TEA's four pillars ![four pillars](https://github.com/tearust/tea-docs/raw/main/res/s8.jpg) -In general, TEA is based on four technologies: -- Substrate: This is layer 1 of T-rust. The blockchain runs consensus on Proof-of-Trust, and immutably stores, processes, and verifies PoT (the hashes from the hardware chips). -- IPFS: This is the file system and network layer of T-rust. All public code and data are stored in IPFS, but all secrets are kept inside TEA modules (the HSM). -- Trusted Computing: This is where the hardware root of trust comes from. We use the TPM chips inside the TEA module (HSM) to generate Proof of Trust. -- WebAssembly: All running executable code is in wasm format and runs inside secure wasm runtime except for our OS, runtime, and system providers. +In general, TEA is based on four technologies: +* Substrate: This is layer 1 of T-rust. The blockchain runs consensus on Proof-of-Trust, and immutably stores, processes, and verifies PoT (the hashes from the hardware chips). +* IPFS: This is the file system and network layer of T-rust. All public code and data are stored in IPFS, but all secrets are kept inside TEA modules (the HSM). +* Trusted Computing: This is where the hardware root of trust comes from. We use the TPM chips inside the TEA module (HSM) to generate Proof of Trust. +* WebAssembly: All running executable code is in wasm format and runs inside secure wasm runtime except for our OS, runtime, and system providers. -90% of the source code is written in Rust. The other 6% is written in JS and the remaining 4% in Golang. +90% of the source code is written in Rust. The other 6% is written in JS and the remaining 4% in Golang. For more detail on the TEA project and T-rust framework, you may visit teaproject.org. #### Prior works and demo Gluon is a dApp and a wasm module running on top of T-rust. We currently do not have the Gluon demo running (but it will be available soon). We do have another demo app showing the capability of the T-rust framework. -This demo is a Tensorflow image recognization running on Substrate blockchain. +This demo is a Tensorflow image recognization running on Substrate blockchain. Here is the video link: > Click to play the demo video @@ -162,60 +165,68 @@ Here's another video introduction to the TEA project: [![](https://github.com/tearust/tea-docs/raw/main/res/blog/WX20201215-115720@2x.png)](http://www.youtube.com/watch?v=-NgR3ySWwXg "") > Therefore, we ask the teams to submit (where relevant): +> > * Mockups/designs of any UI components > * API specifications of the core functionality > * An overview of the technology stack to be used > * Documentation of core components, protocols, architecture, etc. to be deployed > * PoC/MVP or other relevant prior work or research on the topic +### Ecosystem Fit -### Ecosystem Fit Are there any other projects similar to yours? If so, how is your project different? There are many existing crypto wallets in the market. They either store the private keys on client devices (phone, hardware wallet) or centralized servers. There are quite a few wallets in Web3 applications. For example: [bdwallet](https://github.com/tearust/Open-Grants-Program/blob/master/applications/bdwallet.md), or [subwallet](https://github.com/tearust/Open-Grants-Program/blob/master/applications/subwallet.md) -Gluon has a very decentralized approach. We do not store the original keys anywhere. Instead, we use the TEA project's decentralized trusted computing infrastructure to scramble, store, and multisign. This approach prevents users from losing or leaking their keys. +Gluon has a very decentralized approach. We do not store the original keys anywhere. Instead, we use the TEA project's decentralized trusted computing infrastructure to scramble, store, and multisign. This approach prevents users from losing or leaking their keys. A few crypto wallets outside of the Polkadot ecosystem are a little bit similar to ours. [ZenGo](https://zengo.com/security/) provides "passwordless" but still require centralized servers to store encrypted secrets. We do everything decentralized. -[Recovery pellets](https://github.com/paritytech/substrate/tree/master/frame/recovery) is not a wallet but a Substrate pellet with the social recovery idea. We did not know it until we search for a similar project just now. +[Recovery pellets](https://github.com/paritytech/substrate/tree/master/frame/recovery) is not a wallet but a Substrate pellet with the social recovery idea. We did not know it until we search for a similar project just now. [Ledger](https://www.ledger.com/) or [Trezor](https://trezor.io/) are hardware wallets. We do not sell hardware wallet units to end-users. We provide Trust-as-a-Service instead. ## Team :busts_in_silhouette: ### Team members + * Name of the team leader: Kevin Zhang -* Names of team members: +* Names of team members: + - William Zhang -- Jacky Li -- Raindust Yan -- Zehua Jiang -- Lex Pablo +* Jacky Li +* Raindust Yan +* Zehua Jiang +* Lex Pablo ### Contact + * **Contact Name:** Kevin G. Zhang * **Contact Email:** kevin.zhang.canada@gmail.com * **Web site:** teaproject.org gluonwallet.com -### Legal Structure +### Legal Structure + * **Registered Address:** 4006 Hastings Park Ct, San Jose, CA 95136 U.S.A. * **Registered Legal Entity:** Elk Insight LLC. ### Team's experience + Please describe the team's relevant experience. If the project involves development work, we'd appreciated if you can single out a few interesting code commits made by team members on their past projects. For research-related grants, references to past publications and projects in a related domain are helpful. The TEA-Project started in the year 2019. The idea originally came to the team leader, Kevin Zhang, seven years ago when working as the CTO of iHealthLabs. Utilizing patients' health data for scientific research while preventing health data breaches has always been a major problem. He initially tried to solve the dilemma using blockchain but realized that the existing blockchain technologies were far too slow to be practical. He then decided to add the root of trust alongside existing blockchain cryptography + consensus. This is the hardware root of trust. TEA uses existing mature Trusted Computing technologies to provide secure computing services to client blockchains without requiring specialized CPU features such as Phala's (TEE) Intel SGX CPU or Bitcoin's ASIC CPU. Besides the Tensorflow demo app on TEA, making a practical crypto wallet can demonstrate how TEA can do better, so they started the Gluon. The full story of the project can be found here: [Sweeping Monk Medium Blog] (https://pushbar.medium.com/0-of-n-cover-letter-of-the-trusted-webassembly-runtime-on-ipfs-12a4fd8c4338) ### Team Code Repos + * https://github.com/tearust/Gluon_Actor * https://github.com/tearust/Gluon_Pellet * https://github.com/tearust/gluon-docs * https://github.com/tearust/tea-docs ### Team LinkedIn Profiles + * https://www.linkedin.com/in/kevingzhang/ * https://www.linkedin.com/in/zhijun/ * https://www.linkedin.com/in/jacky-li-4039747b/ @@ -223,28 +234,31 @@ The TEA-Project started in the year 2019. The idea originally came to the team l * https://www.linkedin.com/in/zehua-jiang-7494a8203/ * https://www.linkedin.com/in/lex-pablo-a638941ba/ -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: > This section should break out the development roadmap into several milestones. Since the milestones will appear in the grant contract, it helps to describe the functionality we should expect, plus how we can check that such functionality exists in the product. Whenever milestones are delivered, we refer to the contract to ensure that everything has been delivered as expected. -Below, we provided an **example roadmap**. In the descriptions, it should be clear how the project is related to Substrate and/or Polkadot. We recommend to fit the scope of the work within a 3 month period and for teams to structure their roadmap as 1 month = 1 milestone. +Below, we provided an **example roadmap**. In the descriptions, it should be clear how the project is related to Substrate and/or Polkadot. We recommend to fit the scope of the work within a 3 month period and for teams to structure their roadmap as 1 month = 1 milestone. For each milestone: + * Please be sure to include a specification of your software. Treat it as a contract - the level of detail must be enough to later verify that the software meets the specification. To assist you in defining it, we created a document with examples for some grant categories [here](../src/grant_guidelines_per_category.md). * Please include the total amount of funding requested per milestone. * Please note that we require documentation (e.g. tutorials, API specifications, architecture details) in each milestone. This ensures that the code can be widely used by the community. * Please provide a test suite, comprising unit and integration tests, along with a guide on how to run these. -* Please commit to providing a dockerfiles for the delivery of your project. +* Please commit to providing a dockerfiles for the delivery of your project. * Please indicate the milestone duration, as well as a number of Full-Time Employees working on each milestone, and include the number of days along with their cost per day. * Deliverables 0a-0d are mandatory and should not be removed, unless you explicitly specify a reason within the PR's `Additional Notes` section (e.g. Milestone X is research-oriented and as such there is no code to test) ### Overview + * **Total Estimated Duration:** 5 months * **Full-time equivalent (FTE):** 2.5 FTE * **Total Costs:** 28k USD ### Milestone 1 Example — Web app and mobile app pairing + * **Estimated Duration:** 4 Weeks * **FTE:** 2.5 FTE * **Costs:** 5.6k USD @@ -268,6 +282,7 @@ To assist you in defining it, we created a document with examples for some grant | 3.1 | Gluon substrate pellet: Search API | Search user public information | ### Milestone 2 - Phone upgrading and social recovery + * **Estimated Duration:** 4 Weeks * **FTE** 2.5 FTE * **Cost:** 5.6k USD @@ -288,13 +303,14 @@ To assist you in defining it, we created a document with examples for some grant | 4.1 | Layer1 | Suspend old account activity during the recovering process | | 4.2 | Gluon TeaLeaf | Generate a new account to accept assets | | 5.0 | Layer1 | Verify all social recovery confirmation, transfer assets to new account | - + ### Milestone 3 - Generate DOT asset on test net + * **Estimated Duration:** 4 Weeks * **FTE:** 2.5 FTE * **Costs:** 5.6k USD -Prerequisites: -This milestone require Schnorrkel threshold signature issue https://github.com/w3f/schnorrkel/issues/11 completes. +Prerequisites: +This milestone require Schnorrkel threshold signature issue https://github.com/w3f/schnorrkel/issues/11> completes. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | @@ -314,10 +330,11 @@ This milestone require Schnorrkel threshold signature issue https://github.com/w | 4.1 | Gluon TeaLeaf | Executor aggregates public key from initial pinners | | 4.2 | Gluon TeaLeaf | Delegator verify and response to Layer 1 | | 4.3 | Gluon TeaLeaf | Suspend old P2 P3 when a social recovery task in progress| -| 5.0 | Layer1 | Create Schnorr multisig test chain | +| 5.0 | Layer1 | Create Schnorr multisig test chain | | 5.1 | Layer1 | Update user assets | ### Milestone 4 - Sign DOT transaction on testnet + * **Estimated Duration:** 4 Weeks * **FTE** 2.5 FTE * **Cost:** 5.6k USD @@ -337,8 +354,9 @@ This milestone require Schnorrkel threshold signature issue https://github.com/w | 4.0 | Gluon TeaLeaf | Executor find pinners and organize them to multisign tx individually | | 4.1 | Gluon TeaLeaf | Executor verify and aggregates signatures. Send the P2 signatures to test net | | 5.0 | Layer 1 | Settle payment distribution | - + ### Milestone 5 - Migrate to real hardware and test on Polkadot + * **Estimated Duration:** 4 Weeks * **FTE** 2.5 FTE * **Cost:** 5.6k USD @@ -359,13 +377,13 @@ This milestone require Schnorrkel threshold signature issue https://github.com/w Gluon will be a full-featured demo application for the TEA project once it is ready. So far, there are a few limitations that we are working on. -- Integrate with [Parsec](https://github.com/parallaxsecond/parsec). Parsec can be an abstract layer between TeaRuntime and security-related hardware. It makes TEA agnostic to different hardware platforms. It may increase the adaption of TEA. - - Besides DOT, we will all Polkadot ecosystem chains and other Schnorr signature compatible chains. - - We will retire our facade interface service and use off-chain workers instead. - - Besides hardware protection and Schnorr Multisig algorithm, we open eyes to SMPC and FHE algorithm such as BLS Signature Scheme. +* Integrate with [Parsec](https://github.com/parallaxsecond/parsec). Parsec can be an abstract layer between TeaRuntime and security-related hardware. It makes TEA agnostic to different hardware platforms. It may increase the adaption of TEA. +* Besides DOT, we will all Polkadot ecosystem chains and other Schnorr signature compatible chains. +* We will retire our facade interface service and use off-chain workers instead. +* Besides hardware protection and Schnorr Multisig algorithm, we open eyes to SMPC and FHE algorithm such as BLS Signature Scheme. Most items in this to-do list are part of the TEA Project plan. When TEA is ready, most of the features will be available too. ## Additional Information :heavy_plus_sign: -We started the TEA project in 2019. It has been under the radar until recently when it was released to the public. We believe the TEA project could grow large and become the backend service platform for a new type of dApps. These dApps can go beyond the limit of traditional blockchain technologies. Gluon is just one of the many possible demo apps. Once our honor gets granted, we will start looking for investors and hire a CEO and more developers to join us. We hope to maintain a long term and close relationship with the Polkadot community. +We started the TEA project in 2019. It has been under the radar until recently when it was released to the public. We believe the TEA project could grow large and become the backend service platform for a new type of dApps. These dApps can go beyond the limit of traditional blockchain technologies. Gluon is just one of the many possible demo apps. Once our honor gets granted, we will start looking for investors and hire a CEO and more developers to join us. We hope to maintain a long term and close relationship with the Polkadot community. diff --git a/applications/Grant_management_webapp.md b/applications/Grant_management_webapp.md new file mode 100644 index 00000000000..1218c5736c7 --- /dev/null +++ b/applications/Grant_management_webapp.md @@ -0,0 +1,184 @@ +# Grant Management Webapp + +- **Team Name:** Antier Solutions Pvt. Ltd. +- **Payment Address:** Fiat +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + +This application is in response to the open RFP: https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/grant_management_webapp.md + +### Overview + +The Grant Management Web Application is a comprehensive software solution designed to streamline and enhance the process of managing grants. It aims to provide w3f and other grant-making institutions with a centralized platform to efficiently handle grant applications, evaluation, tracking, reporting, and overall administration. By reducing the number of clicks, the web application will enable better navigation of data, better UI, greater ease and effectiveness in the grant management process. + +### Project Details + +#### Key Features: + +- Organised relevant data. +- Github API integration to carry out relevant actions. + +Technical Architecture + +![Grant Management Webapp(draft 2)-Technical Architecture (1)](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/e24b6156-b755-40ae-bc09-624c75e860fc) + +- Mockups/designs of any UI components + +### Core Components: + +#### Front-End: +1. UI: +- Project Dashboard: ![image_2023_05_25T13_03_13_705Z](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/57801170-bdf1-4a5f-aead-05b4c2c7402b) + +- Project Details: ![image_2023_05_25T13_03_13_706Z](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/a2518aad-0d3c-4c39-a829-6b8d52f483b4) + +- Team Dashbard: ![image_2023_05_25T13_03_13_710Z](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/db6dc265-b0f2-4d87-909b-9c71803821cb) + +- Team Details (applications): ![image_2023_05_25T13_03_13_710Z](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/aaca6386-9f96-4f09-a93a-c3670662ffa9) + +- Team Details (projects): ![image_2023_05_25T13_03_13_709Z](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/a63aa155-5e74-4fb1-adf5-cb395f609308) + +- Application Dashboard: ![image_2023_05_25T13_03_13_703Z (1)](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/0dcb6be4-2e24-4a5a-975b-c6f0ace10f51) + +The discussions, commit, and file changes pages will be designed same as they are shown on a PR in github. Approvals, reviews and rejections will be handeled in the discussions tab +- Application Details: ![image_2023_05_25T13_03_13_703Z (2)](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/117f4eff-a6a4-4782-905d-f4abc62ecd1e) + +- Delivery Dashboard: ![image_2023_05_25T13_03_13_704Z (2)](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/16fd5ba0-a4de-47eb-a23a-624bed68177c) + +- Delivery Details: ![image_2023_05_25T13_03_13_704Z (1)](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/cd96dc63-ed61-4f80-ab8b-16aa87337321) + +2. Back-End API Integrations + +#### Back-End: +1. Front-End API Integrations +2. Github API Integrations +3. Database API Integration +4. Cron Job +5. Data Extractor - Service that extracts data from the MD files for storage +6. Web Hook Handler - Service that will listen to events and then handle the respective functionality + +#### Database +![Grant Management Webapp(draft 2)-DB final draft (1)](https://github.com/lawmeskiviahs/Grants-Program/assets/60818312/f133eaba-caca-4ceb-add4-8268d08226a7) + +### Things not included in the project: + +There is no wallet support/oracle for treasury pallet in this application but these can be integrated upon further discussion. + +### Technology Stack + +- Front-end: HTML5, CSS3, JavaScript (React) +- Back-end: Node.js (Express.js) +- Database: MongoDB +- Authentication and Authorization: Github (github apps) +- Cloud Hosting: Github Marketplace + +### Ecosystem Fit + +The W3F grants program is growing by the day. It is quite a hassle for the grants committee to browse the Grant Program Repositories. This application aims to achieve two things: 1. Consolidate releveant information from the Grant Program Repos; 2. Provide Github Actions functionality to deal with the process of the Grant Program within the app itself. + +## Team :busts_in_silhouette: + +### Team members + +- Kulwinder Singh (Backend) +- Shaivik Semwal (Frontend) +- Aanchal Kathuria (Tester) + +### Contact + +- **Contact Name:** Karan Chopra +- **Contact Email:** karan.chopra@antiersolutions.com + +### Legal Structure + +- **Registered Address:** E-221, Phase 8B, Industrial Area, Sector 74, Sahibzada Ajit Singh Nagar, Punjab 160059 +- **Registered Legal Entity:** Antier Solutions Pvt. Ltd. + +### Team's experience + +- Antier is a thought-to-finish partner for customers in their blockchain journey. We advise and consult our clients on blockchain technologies and tailor solutions utilising our powerful blockchain ecosystem. We help customers experiment and deploy proof-of-concepts on blockchain technologies and incrementally expand to scale to production releases. Our thought leaders regularly educate customers, partners, CXOs on the power of blockchain for today and tomorrow. +- Workdone by Antier in Substrate ecosystem +1. Antier worked on the validator and nominator apps for substrate based blockchains to offer a unique and better user experience . +2. We have also worked on creating an optimised and homogenised design focused on improving the navigation, information architecture, user flow tasks, content design and graphic elements for a seamless and easy browsing experience. +3. We have customised the default reward mechanism in the staking pallet of the substrate chain by integrating the sustainability and reliability score(which is calculated by ESG scores and Uptime of the validators repectively) of the validators in the current reward system. +4. We were able to run EVM and WASM machines natively in the substrate chain so that the chain will be able to support both EVM(Metamask, Remix, Web3.js, etc) and WASM(WebAssembly target, INK framework, etc) tooling. +5. We were able to replicate the whole polkadot ecosystem(Relay chain, Parachains, XCM), Where parachains are use case specific chains and communicate through XCM protocol with each other. + +- Our team has been proactively participating in the Substrate Stack exchange and we ask/answer question related to ink!, Substrate, parachain. We rank in the top 6% people in the Substrate Stack Exchange. + +- Profiles of our team: +1. https://substrate.stackexchange.com/users/2372/arunjot-singh +2. https://substrate.stackexchange.com/users/2281/amit-kumar-yadav +3. https://substrate.stackexchange.com/users/354/shubham-gupta + +- Our organisation is the technical partner for 5ire chain: https://5ire.org/ + +- Our team has worked on multiple IDE which include an EVM compatible IDE for solidity, IDE for WASM contracts for ink! based smart contracts. The EVM IDE is live and the link is : https://ide.5ire.network/ + +### Team Code Repos + +- Kulwinder Singh https://github.com/kulwindersingh-ant +- Shaivik Semwal https://github.com/lawmeskiviahs + +### Team LinkedIn Profiles (if available) + +- Kulwinder Singh https://www.linkedin.com/in/kulwinder-singh-394384130 +- Shaivik Semwal https://www.linkedin.com/in/shaivik-semwal-468a13202 + + +## Development Status :open_book: + +A minimal POC has been made wherein the basic github actions were successfully tested. +Things tested in POC: +1. Created issue in a repo +2. Fetch list of issues in a repo. +3. how to use responses. +4. Get PR list to a repo +5. Get PR by number +6. Merge a PR +7. Get comments on a PR +8. Update a comment on PR +9. Add comment on PR + +- POC (code)- [ghApi](https://github.com/lawmeskiviahs/ghApi) +- POC (tested on) [helloGhpi](https://github.com/lawmeskiviahs/helloGhapi) +- [Github API Ref Sheet](https://docs.google.com/spreadsheets/d/1RWB4XAMFj-tKU4nXEDN0ZUXXmVq1gLpEMqFp_WRPthg/edit?usp=sharing) + +Github provides REST API for a lot of github actions. The link to the API docs is [here](https://docs.github.com/en/rest?apiVersion=2022-11-28) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 8 weeks +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 10,000 USD + +### Milestone 1 — Teams and Projects + +- **Estimated duration:** 8 weeks +- **FTE:** 3 +- **Costs:** 10000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can browse through the application and perform github actions | +| **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. | Frontend | We will provide dashboard and details pages for Projects and Teams with all details | +| 2. | Backend | Database integrations and data extractor will be implemented. i.e data from the md files on github will be processed and saved to the database using API | +| 3. | Backend | Github API integrations and web hooks will be implemented so that our application can listen to events and make necessary changes in the db | +| 4. | Data Base | DB schema implementation | + + +## Future Plans + +We plan to deliver the following after receiving the Grants Committee's approval : + +Oracle for treasury pallet integration is being researched meanwhile and also looking for decentrallised alternative for github. Upon further discussions with the grants committee we shall go ahead with this + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Grants Portal \ No newline at end of file diff --git a/applications/GreenLemon.md b/applications/GreenLemon.md new file mode 100644 index 00000000000..0ae0a06399a --- /dev/null +++ b/applications/GreenLemon.md @@ -0,0 +1,165 @@ +# Green Lemon + +- **Team Name:** Green Lemon +- **Payment Address:** 0xf4f463B9A0ADa68536423121e7Bf9E559ce54fAf(Ethereum ERC20 USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +[Proposal: Dual-Key Stealth Address Protocol](https://github.com/w3f/Grants-Program/pull/997) + +[Milestone Delivery: Dual-Key Stealth Address Protocol](https://github.com/w3f/Grant-Milestone-Delivery/pull/504) + +### Overview + +Many of today’s blockchains, including Bitcoin and Ethereum, are open and public ledgers in the sense that there are no restrictions on participation and all transaction details are visible on the blockchain. In a public ledger, the transaction entities are only identified by their blockchain addresses, which are derived from the corresponding public keys. Public ledgers are generally considered to be “pseudo-anonymous”, which means that an address is linked to one person, but that person is unknown to the public. However, by analyzing the transaction graph and combining it with other information, it is possible to reveal the true real-world identity behind a blockchain address, as shown by recent research. + +The Green Lemon protocol is an anonymous NFT solution for the Polkadot ecosystem based on zero-knowledge proof and dual-key stealth address protocol: users deposit DOT to an anonymous NFT contract and then anonymously send mint, transfer, and other ERC721 functions to that contract via relayer. + +### Project Details + +The protocol implements the function of initiating anonymous transactions through zero-knowledge proofs and the function of hiding NFT owners through DKSAP. + +Currently, a large number of anonymous transaction projects use zero-knowledge proofs, such as Monero and ZCash based on the UXTO model, and Zether and Tornado based on the account model. + +Zether comes to our attention with its unique implementation, which uses the Σ-Bullets protocol, does not require the generation of public parameters for the initiation ceremony, and uses the Elgamal encryption algorithm for homomorphic encryption and decryption of account balance, which are excellent features. But the Gas for anonymous transfers involving 64 accounts verified amounted to 36,152,558 on Ethereum virtual machine. + +Meanwhile, Tornado, based on zk-SNARK, performed well in terms of Gas, with a Gas consumption of 1,088,354 for deposits and 301,233 for withdrawals. After comparison, we decided to develop a zero-knowledge proof module based on zk-SNARK. + +DKSAP is a new privacy transaction protocol invented by rynomster/sdcoin in 2014. Since its announcement, it has landed in numerous blockchain projects (Monero, Samourai Wallet, TokenPay, etc.). It is characterized by the fact that the account needs to generate two sets of public and private key pairs, "scan key pair", and "spend key pair", the recipient of each transaction is encrypted and cannot be associated with a particular blockchain account. + +The protocol contains the following functions: + +* Deposit: The user generates a random note and deposits a coin to the NFT anonymous contract, so that can pay the relayer fees for anonymous transactions. + +* Withdrawal: The user will get back the DOT previously deposited, and nullifier the corresponding note. + +* Registration: The user registers the Scan public key and Spend public key to the NFT contract, and if the relayer sends the transaction to the chain, the user needs to pay the fee for the relayer. + +* Mint: The user generates the encrypted public key address ePub1(encrypted pub key) based on his scan pub and anonymously mint NFT through the relayer, the owner of this NFT is ePub1, and the user needs to pay the gas fee to the relayer. + +* Transfer: The user generates the encrypted public key address ePub2 based on the scan pub of the recipient and uses the private key signature corresponding to ePub1 to anonymously transfer the NFT, and the owner of the NFT is ePub2, and the user needs to pay a fee to the relayer. + +* Burn: The user pays the fee to relayer to burn NFT. + +* Other functions supported by ERC721, including Approval, ApprovalForAll, clear_approval, and set_approval_for_all. + + +### Ecosystem Fit + +NFT sales reached $17.7 billion in 2021, up from $82.5 million in 2020 — a jump of more than 200 times. Total NFT profits when reselling or buying also skyrocketed from $12 million in 2020 to $5.4 billion in 2021. + +Sotheby's - a renowned auction house with a history of nearly 300 years - generated $7.3 billion in sales in 2021, of which 10% was in private transactions. + +This gives us confidence that anonymous trading, the act of buying and selling without revealing the identity of the trader, is just as strongly demanded in the NFT ecosystem. + +As the first anonymous NFT application of web3 Ecology, we believe Green Lemon will have a positive impact on Polkadot. Users of NFT who value their privacy greatly will find it attractive. + + +## Team :busts_in_silhouette: + +### Team members + +Yahuang Wu + +* [Github address](https://github.com/wuyahuang) +* Educated in Xiamen University, MEM +* 7 years of internet R&D experience, participated in the development of several apps with millions of Daily Active Users (Qunar, Snowball, Meiyou) +* Head of the technical team of EOS genesis block producer +* Author of 40 EOS technical articles [list of technical articles](https://github.com/meet-one/documentation/blob/master/meetone-lab-docs.md) +* Selected into the EOS Open Source Community Acknowledgments List [list of selected lists](https://steemit.com/eos/@liondani/eos-acknowledgments-making-it-immutable-via-steemit) +* EOS Hongkong Hackathon tech mentor +* Contributed code to several repositories in the 2020 GitHub Archive Program +* 10 blockchain technology patents [Patent List](http://www1.soopat.com/Home/Result?SearchWord=%E5%90%B4%E4%BA%9A%E7%9A%87&FMZL=Y&SYXX=Y&WGZL=Y&FMSQ=Y) + + +Rick + +* Educated in Xiamen University, Computer Science & MBA +* Head of the technical team of Meiyou APP (one of the most famous female health APP in Aisa) +* Head of the technical team of EOS wallet (one of the most famous EOS wallets in Asia) + +### Contact + +- **Contact Name:** Yahuang Wu +- **Contact Email:** wuyahuang@gmail.com +- **Website:** https://github.com/GreenLemonProtocol + +### Legal Structure + +- **Registered Address:** +- **Registered Legal Entity:** + +### Team's experience + +We have 10 years of experience in Internet research and development, focusing on the blockchain industry since 2018. We are deep participants in several technical communities, hackathon winners, and node service providers for EOS and PlatON. + +### Team Code Repos + +- Green Lemon Protocol: https://github.com/GreenLemonProtocol + +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. + +- Yahuang Wu: https://github.com/wuyahuang +- Rick: https://github.com/MeetYouDevs + +## Development Status :open_book: + +[Milestone Delivery: Dual-Key Stealth Address Protocol](https://github.com/w3f/Grant-Milestone-Delivery/pull/504) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 12 weeks +- **Full-Time Equivalent (FTE):** 2 +- **Total Costs:** 30,000 USD + +### Milestone 1 — Implement anonymous NFT based on ERC721 + +- **Estimated duration:** 3 weeks +- **FTE:** 2 +- **Costs:** 8,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Article | We will publish **article & demo video** that explains How is anonymous NFT contract hidden owner works based on dual-key stealth address protocol. +| 1. | (ink!)Smart contracts: Anonymous NFT | [Milestone Delivery: Dual-Key Stealth Address Protocol](https://github.com/w3f/Grant-Milestone-Delivery/pull/504) only implements mint, transfer, and burn. Based on the current version, we will continue to develop other ERC721 protocol methods and related test cases, such as approve, approve_for, get_approved, base_uri, and token_uri. Additionally, we need to add an extra param into the message before hashing, which is the token nonce. Account nonce is unfit due to each token owner being a unique and one-time encrypted address. When an NFT is operated once, its corresponding token nonce is automatically added by 1. We think that token nonce can prevent replay attacks for signatures already sent to the blockchain.| + + + +### Milestone 2 — Implement anonymous transaction + +- **Estimated Duration:** 9 weeks +- **FTE:** 2 +- **Costs:** 22,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Article | We will publish **article & demo video** that explain How is anonymous NFT solution works based on zero-knowledge proof. +| 1. | (ink!)Smart contracts: Anonymous NFT | Development and testing of the core functions of the Anonymous NFT smart contract, including deposit/withdraw DOT from the contract, sending the transaction to the NFT contract through the relayer, and paying the transaction fee to the relayer on-chain. As mentioned above, anonymous transactions are based on zero-knowledge proof.| +| 2. | (Node.js)Relayer service | Development and testing of the relayer service. As mentioned above, All user transactions are sent by the relayer service, and users need to transfer token to the relayer based on zero-knowledge proof.| + + + +## Future Plans + +Please include here + +- Develop PC website and Google chrome extension wallet based on Green Lemon Protocol, lower the threshold for blockchain users +- Add Merkle tree to store notes on-chain, so users can verify that transactions are mined by the blockchain network. + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website + +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: + +[Proposal: Dual-Key Stealth Address Protocol](https://github.com/w3f/Grants-Program/pull/997) diff --git a/applications/High_availability_validator_setup.md b/applications/High_availability_validator_setup.md new file mode 100644 index 00000000000..839f60592b9 --- /dev/null +++ b/applications/High_availability_validator_setup.md @@ -0,0 +1,182 @@ +# High-availability validator setup + + +- **Team Name:** Bright Inventions +- **Payment Address:** 0xD75dDC4Aa3618e1417c68E5Df79ef9D66E4B1Ed9, DAI +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + + +## Project Overview :page_facing_up: + +Validator leader selection via Raft consensus. +This is a follow-up to the previous version of the grant, that was up for discussion with the Parity development team. + +### Overview + +Currently, the recommended setup is to have one active node per validator. The main advantage of this approach is that it removes the danger of equivocation, thus preventing slashing. The key drawback is the lack of a ready backup machine to takeover the responsibility of producing blocks, voting on finality etc. in case the primary one fails. + +The drawback can be somewhat remedied by having a backup node in sync, but without access to the session keys necessary for authoring blocks. The process of replacing the keys, however, is manual. Furthermore, the session keys cannot be replaced mid-session and this introduces a time delay for when the validator is active again. + +### Project Details + +Rather than relying on one validator node to perform the work, what if we had multiple nodes equally capable of taking part in consensus, yet still avoiding the risk of equivocation? + +Since all our validator nodes are trusted and we don't worry about censorship resistance, we can leverage a leader-follower model to ensure high availibility. [Raft](https://raft.github.io/) is a good candidate - it offers a simple consensus mechanism, fault-tolerance and performance. It ensures only one leader is ever in charge of interacting with the network, while the followers simply receive the state updates and automatically replace the leader in case of a failure. + +Following the feedback from the Parity developers team our solution is not tightly coupled with Substrate node as it adds too much complexity in the node. It should be implemented in a way that makes this optional and loosely coupled with the node. + +### Ecosystem Fit + +The goal is to present a solution that would update the current recommended setup of one active node per validator and allow to use multiple nodes. + +## Team :busts_in_silhouette: + +### Team members + +- Katarzyna Łukasiewicz +- Kasper Ziemianek +- Michał Graliński + +### Contact + +- **Contact Name:** Katarzyna Łukasiewicz +- **Contact Email:** katarzyna.lukasiewicz@brightinventions.pl +- **Website:** https://brightinventions.pl/ + +### Legal Structure + +- **Registered Address:** ul. Jana Matejki 12, 80-232 Gdańsk, Poland +- **Registered Legal Entity:** Bright Inventions Sp. z o. o. + +### Team's experience + +Bright Inventions is a team of over 70 full-time onsite developers, project managers & UX/UI designers - experts in mobile and web applications, systems integration, IOT devices and Blockchain platforms. + +We believe that building a software product is about people working together in a collective way. By offering complex support – mobile and web development as well as IT consultancy we try to eliminate roadblocks towards engaging clients as partners at every step of the process. + +We support startups, digital agencies as well as medium to big businesses. We cooperate with startups, accelerators and incubators. Whatever the client profile is, we always aim to establish a satisfying partnership for both sides. Since 2012 we have built software for more than 40 businesses worldwide. + +The team: +- Michał - Rust Developer, for over 12 years he has been working as a C++ developer. In his career he participate in various projects, starting from the embedded devices, automotive, mobile games and ending on the financial systems. Right now he is focused on the blockchain technology. +- Kasper - Software developer with 10 years of experience. Former Java Developer who has recently switched to Rust. Around blockchain ecosystem since 2017. +- Kasia - she has been working with agile methods for over 10 years, both as a researcher and a practitioner. She believes in teamwork and a power of user centered mindset. With experience in leading international projects, she knows how to support and encourage timely and high quality deliveries. + +Previous grants that the team members were involved in: +- BrightTreasury +- ZK-Snarks tutorial in Substrate + +### Team Code Repos + +- https://github.com/bright/substrate + +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/bufta +- https://github.com/kziemianek +- https://github.com/mgralinski-bright + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/katarzyna-łukasiewicz-b473901aa/ +- https://www.linkedin.com/in/kziemianek/ +- https://www.linkedin.com/in/michal-gralinski-b464152/ + + +## Development Status :open_book: + +This grant proposal is a follow-up to a discussion that began in autumn 2022. Since then we managed to receive some required feedback from Parity development team and we continued to apply their suggestions in the span of these few months. It allowed us to already develop most of the original scope. + +## Development Roadmap :nut_and_bolt: + + +### Overview + +The development of the specified goal will be broken into 3 milestones, lasting 4 weeks (M1), 3 weeks (M2) and 2 weeks (M3). + + +Definition of Done for each deliverable: +
            +
          • Unit tests passed
            • +
          • Code has been reviewed by peer
            • +
          • Acceptance criteria were met
            • +
          • Internal QA has been performed
            • +
          • Documentation has been written
            • +
          + + +At the end of each milestone: +- The deliverables listed for the given milestone have been implemented and the DoD criteria were met, allowing the user to perform the defined actions +- The functioning code has been pushed to the public repository, indicated in the proposal + +## Deliverables :nut_and_bolt: + +* **Total Estimated Duration:** 9 weeks +* **Full-time equivalent (FTE):** 1 +* **Total Costs:** 25,000 DAI + +### Milestone 1 - Block authoring, finalization & liveness PoC + +The goal of the first milestone will be adding a switch to the substrate codebase, which will conditionally allow block production, voting or sending `I'm online` message. We will achieve this by introducing a `PermissionResolver` trait. Only for the purpose of this milestone there are going to be two trivial implantations of this trait. First configuration will grant the validator permissions and the second one will not. At this stage we only want to verify if hardcoded conditional logic works well with the nodes with the same auth key but different configurations (permission granted/denied). For the testing purpose we will provide an additional option to the CLI, to run a validator with one of the pointed configurations. + +* **Estimated Duration:** 4 weeks +* **FTE:** 1 +* **Costs:** 12,500 DAI + +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **0b.** | Documentation | We will provide inline documentation.| +| **0c.** | Testing and Testing Guide | We will provide unit tests and the guidelines for running and testing it the scope. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Update substrate | Modify the substrate code to conditionally submit blocks/votes for finalised blocks (GRANDPA)/`I'm online` messages. | +| 2. | Update substrate client - cli | Modify the substrate code to conditionally grant or permit permissions. There will be option to run node in permission granted or permission denied mode). It will be useful to prove that permissioning works by running two nodes with same auth keys but different modes (permission granted/denied) | +| 3. | Integration test | A dockerised setup that allows to run network in setup described above. | + +### Milestone 2 - External service for permission granting + +The second milestone introduces a microservice which will test dynamic switching of the permission granting, during the validator's work. We will be able to test permission granting triggered whenever the block is produced, the vote is made on the finalized block (GRANDPA) and a message (`I'm online`) is sent for communicating liveness. Only the leader validator will be granted to run those actions. At worst, the author may miss a slot. + +The service should contain only basic logic (e.g. return `true` for node that asked first and `false` for following ones). + + +* **Estimated Duration:** 3 weeks +* **FTE:** 1 +* **Costs:** 7,500 DAI + +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **0b.** | Documentation | We will provide inline documentation.| +| **0c.** | Testing and Testing Guide | We will provide unit tests and the guidelines for running and testing it the scope. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Basic service | Create a microservice that accepts connections from the node. | +| 2. | Getting permission from microservice | Set up a custom node repository and write the `PermissionResolver` trait implementation for getting permission from the microservice. | +| 3. | Allow as optional | The choice of using an outside decision making agent for block submission should be configurable in the cli. | +| 4. | Clean up substrate code | Remove deprecated cli options. | +| 5. | Integration test | A dockerized setup that allows to run custom node networks and a microservice in order to show that the created solution works. | + +### Milestone 3 - Raft based current leader selection + +Replace the dummy microservice as an infrastructure component with a [TiKV](https://github.com/tikv/tikv) cluster used for leader selection. +Each node should try to get authorship permission based on the KV (Key-value) state. Replace the current microservice client with a TiKV client and add corresponding logic. + +* **Estimated Duration:** 2 weeks +* **FTE:** 1 +* **Costs:** 5,000 DAI + +| Number | Deliverable | Specification | +| ------------- | ------------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **0b.** | Documentation | We will provide inline documentation.| +| **0c.** | Testing and Testing Guide | We will provide unit tests and the guidelines for running and testing it the scope. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1. | Run the necessary Raft services | Set up a local dev infrastructure to run TiKV components in order to provide a distributed KV store. | +| 2. | Integrate a Raft client into the node | Replace the previous logic with a TiKV based one and modify configs to allow the TiKV client to connect to Placement Drivers. Placement Drivers (PD) is one of the components which stores metadata for the entire TiKV cluster. It is responsible for sending commands to the TiKV nodes. The minimum setup for PD is to manage three TiKV nodes. | +| 3. | Integration test | A dockerised setup that allows to test the Raft consensus mechanism. | + + + +#### Leader selection process + +![](https://i.imgur.com/ummEJOK.png) +Similar for rounds and sessions. diff --git a/applications/Hyperdot.md b/applications/Hyperdot.md new file mode 100644 index 00000000000..bb9f7be6619 --- /dev/null +++ b/applications/Hyperdot.md @@ -0,0 +1,192 @@ +# Hyperdot - Powerful data analysis and creation platform — RFP + +- **Team Name:** Infra3 +- **Payment Address:** [0xDc2c1814639f113C6EB51b3D8d871372Da9e116A](https://etherscan.io/address/0xDc2c1814639f113C6EB51b3D8d871372Da9e116A) (Ethereum ERC20 USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview 📄 + +This is a response for the [Analytics Website/Data Platform](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/analysis-website-and-data-platform.md) RFP. + +### Overview + +Crypto data is growing rapidly, and large data companies are not consider integrating them into their systems. However, multi-chain crypto data is of significant value to users. The hyperdot is a on-chain data platform for querying, analyzing, and creations, written in Rust. It provides users with powerful capabilities for data querying, analysis, and creations. + +With hyperdot, users can easily query and analyze crypto data from **Polkadot**, **Kusama**, and other **parallel chains built on the Substrate Runtime**. Hyperdot separates the indexing and computation of on-chain crypto data from the off-chain data storage, analysis, and querying, addressing scalability issues present in many data analysis platforms. Hyperdot offers multiple data engines to adapt to different scenarios. + +Hyperdot provides a dashboard similar to [Dune Analytics](https://dune.com/browse/dashboards) and [Chainbase](https://chainbase.com/), offering powerful data analysis and visualization features currently. Users can create queries using different data engines and generate visual data dashboards. Importantly, Hyperdot is dedicated to building a data analysis creations community where data engineers and data scientists can create and share their work based on Hyperdot's data, fostering collaboration and knowledge exchange. + + +### Project Details + + +#### The System Overview + +The Hyperdot project consists of two main system: hyperdot-node and hyperdot-frontend-end. + +hyperdot-Node will ideally integrate the data source of [substrate-etl](https://github.com/colorfulnotion/substrate-etl) to provide an crypto-data query api on the chain + +hyperdot-frontend-end is built using [tailwind css](https://tailwindcss.com/) and [next.js](https://nextjs.org/), creating a modern web dashboard. While it works similar to Dune Analytics, it has its own unique features. Hyperdot-Frontend connects to Hyperdot-Node to provide users with user-friendly chain data analysis capabilities. Moreover, it aims to establish a data analysis community where data engineers and data scientists can create and share insights based on the data provided by Hyperdot. + +#### The System Architecutre + +Hyperdot will consider the success of the existing work of the integration community, for example, on the data source, we will choose to integrate [substrate-etl](https://github.com/colorfulnotion/substrate-etl) as the data of hyperdot-node-front engine, at the same time, in order to maintain good scalability, hyperdot-node will also retain other options. + + +![Hyperdot System Architecture](https://raw.githubusercontent.com/Infra3-Network/hyperdot/dev/docs/imgs/hyperdot-arch2.drawio.png) + +The system is mainly divided into three parts +1. substrate-etl provides the relevant data warehouse, other ecosystems allow us to customize the index, and we will integrate their data as the data source of the system on demand +2. hyperdot-Node will integrate data from common bins provided by substrate etl and provide apis for hyperdot-front-end +3. hyperdot-fronted-end provides a user-friendly front-end interface for data analysis, exploration, and collaborative data analysis creation. It is built using modern front-end technologies. The interaction between hyperdot-fronted-end and hyperdot primarily utilizes HTTP, while GraphQL is used for handling complex data queries. WebSockets are employed for subscription-based data updates. + +#### The Live Demo + +We have deployed a small [live demo](https://playground.infra-3.xyz/) that you can play directly with. + +Querying westend testnet block data + +![query1](https://raw.githubusercontent.com/Infra3-Network/hyperdot-front-end/main/docs/imgs/playground.png) + +Querying the westend block data uses the index + +![query2](https://raw.githubusercontent.com/Infra3-Network/hyperdot-front-end/main/docs/imgs/query.png) + +### Ecosystem Fit + +hyperdot will integrate data from Polkadot, Kusama, and Substrate networks by utilizing the infrastructure of substrate, substrate-etl, and other Parity technology communities. It will support multi-chain and multi-runtime environments. hyperdot will provide a dashboard that enables users to easily query on-chain crypto data using SQL language. Additionally, it will establish a community for data querying, analysis, creation, and sharing, allowing users to exchange insights. + +hyperdot is a data querying, analysis, creation, and sharing platform targeting a wide range of users, including data analysts, data scientists, project managers, and anyone interested in analyzing on-chain crypto data using hyperdot. + +Currently, we have not found similar projects in the Substrate/Polkadot/Kusama ecosystems. Moreover, data analysis systems that support multi-chain, multi-data engine integration with good scalability are rare in other ecosystems as well. We firmly believe that hyperdot will bring significant value to the community. + + + +### QA + +**Q:** Come up with a value proposition to make it viable: "how would the project stay sustainable and capture value?" to sustain operating costs + +**A:** + +- **Sustainability:** First, technically, we have a team with a good web3 background, so we don't get stuck with technical issues. Second, we were able to reduce our storage costs by relying on other projects' data warehouses, which allowed our projects to grow healthier. + +- **Capture value:** We believe that the ecosystem needs a "dune for substrate, but better" project that enables more powerful analytics for all users. + +**Q:** Interview a few parachains/ecosystem teams & researchers on the top 3 "dashboards" or interactive data use cases they'd like to see and include how you would solve that as part of the analysis and data platform RFP. + +**A:** We can't give a precise answer to this question, but we did a deep dive last week into existing data analytics projects in the ecosystem and, similarly, they always present data that users expect on top3. hyperdot is a little different, + +1. hyperdot allows anyone to create analytics dashboards using data provided by the substrate-etl repository, so the top3 ranking is not actually controlled by hyperdot +2. However, we provide a favorites ranking for each dashboard, which can accurately show which data analytics dashboards are widely used by the community based on favorites + + + +## Team + +### Team members + +- **Ryan Xiao** + +- **Ming Dai** + +- **Tania** + + +### Contact +- **Contact Name:** Tania +- **Contact Email:** tania.infra3@gmail.com +- **Website:** https://network.infra-3.xyz + +### Legal Structure + +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A + +### Team's experience + +**Ryan Xiao** is a contributor to the Tendermint-rs and Postgres communities and. With nearly 10 years of software development experience, Ryan Xiao is an expert in Rust and C++ programming languages. He specializes in decentralized systems, large-scale distributed data systems, and cloud computing system development. Ryan Xiao has been involved in the development of the Tendermint-rs community and decentralized data systems based on Tendermint-rs and Postgres FDW. He has also contributed to multiple research-oriented databases at CMU, showcasing a deep understanding of databases. Ryan Xiao has conducted extensive research on Web3 consensus protocols and the Substrate framework, published several articles on Substrate development, and organized related presentations. He has been dedicated to helping more technologists become familiar with and understand Web3 development through Substrate. + +**Ming Dai** has been working in decentralized exchanges for the past few years, focusing on data security. He has a strong passion for Rust and Substrate and has conducted extensive research on Substrate pallet and runtime development, backed by rich practical experience. Ming Dai has studied the design and implementation of Dune and has implemented a data analysis system for the company based on Ethereum's chain. Additionally, Ming Dai is familiar with smart contracts, dApps, frontend design, and developm + +**Tania** has been involved in security audits and operational work at exchanges. She is also an excellent UI designer, dApp creator, and technical document writer. Tania has a deep love for Substrate and ink! and has been exploring the use of ink! to refactor previous smart contracts. + +### Team Code Repos + +- https://github.com/Infra3-Network/hyperdot +- https://github.com/Infra3-Network/hyperdot-fronted-end +- https://github.com/Infra3-Network/hyperdot-data-playground + +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/pidb +- https://github.com/bytesleak +- https://github.com/cattania + + +## Development Status 📖 + +In 2022, Ryan started exploring Substrate and The Graph, and at that time, he attempted to add support for Substrate data on The Graph for private chains. This effort lasted for approximately six months. + +Starting from March of this year, Ryan and Ming were inspired by Dune and Chainbase, and they thoroughly studied the architecture design and implementation of these projects. Subsequently, we discussed the feasibility of building a multi-chain, multi-runtime, multi-data engine, scalable platform for web3 data analysis, creation, and a community of web3 data enthusiasts. + +We began designing and implementing Hyperdot, with Tania providing us with a simple data playground. Currently, we have achieved an MVP (Minimum Viable Product) validation of the core components, and they are functioning well. It is estimated that it will take another three months to make them work properly. Therefore, now is the time to apply for a W3F grant and introduce the work we have done to the entire Substrate community. + +## Development Roadmap 🔩 + +### Overview +- Total Estimated Duration: 3 months +- Full-Time Equivalent (FTE): 3 FTEs +- Total Costs: 19,000 USD + + +### Milestone 1 — Completion of all components and core functionalities of hyperdot-node +- **Estimated duration:** 5 weeks +- **FTE:** 3 +- **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 (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| **0e.** | Article | We will publish an **article**/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.) | +| **1.** | SQL Query API | We will use the bigquery client to integrate substrate-etl from the data sources provided by substrate-etl and creating a data query api using the bigquery client and substrate-etl, including

          1. We will integrate the table schema provided by substrate etl to create interfaces for different query capabilities we provide, such as chain information, transaction information, etc.
          2. Show the table-scheme of the associated chain
          3. Run and save sql queries | +| **2.** | Dashboard Editor | The apis needed to implement the dashboard, including
          1. Edit the visualization dashboard page by loading sql
          2. Save the dashboard you've edited | +| **3.** | Discovery | We will implement the apis required by the discovery feature for data analytics dashboards and data query sharing, including
          1. The dashboards list api
          2. dashboards item Detail api. Each dashboard item is clicked to show the user's previously edited dashboard
          3. queries List api
          4. queries item details api. After clicking each query item, it displays the sql data tables and other information that the user has saved and run before | + + + + + +### Milestone 2 — Completion of all components and core functionalities of hyperdot-fronted-end +- Estimated duration: 7 weeks +- FTE: 3 +- Costs: 10,000 USD + +| Number | Deliverable | Specification | +| ------: | ------------------------------ | ------------------------------------------------------------ | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| **0e.** | Article | We will publish an **article**/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.) | +| **1.** | Page Layout | We will provide the basic layout, which will
          1. A basic header navigation and routing
          2. Dashboard, Queries | +| **2.** | Data Creation - New Query Page | We will provide data analysis querying and creation on the Data Creation Page, and an interactive data analysis querying experience on the New Query Page:

          1. New Query Page: This page will display the supported data engines and the associated tables for each engine.
          2. Playground Editor: Users will be able to input SQL queries in an interactive manner using the Playground Editor.
          3. Dynamic Table: The results of data analysis will be presented using a dynamic table.
          4. Visual Chat: We will incorporate a visual chat feature to enhance the objectivity of the data.
          5. Save and tag created data queries: Users will have the ability to save their created data queries and add tags to them. | +| **3.** | Data Creation - New Dashboard | New Dashboard allows users to create shareable dashboards that it will
          1. Create a Dashboard form
          2. Visualize the Query created by the user in the New Query Page | +| **4.** | Discovery - Queries | The Discovery Queries section will showcase data analysis queries created by users in the community. Each creation can be clicked to access the details, where the Playground Editor will explain the SQL syntax and display relevant visualized data tables. | +| **5.** | Discovery - Dashboards | The Discovery Dashboards section will show shared visual dashboards created by users in the community. You can click on each creation to access the details, and once inside you can load a dynamic dashboard based on your query. | + + +## Future Plans + +After completing hyperdot and releasing the first version, we will integrate more data engines, including time series data engines (influxdb), OLAP analytics engines (Clickhouse), and distributed query engines (Spark). + +We will consider indexing more types of data, not just raw chain data, but also decoded dex and not data, as well as additional extrinsic data. Additionally, we plan to establish a mechanism where developers can propose data models they want to index through GitHub or the community. Once adopted, these data models will be incorporated into our data engines. + +We will also consider **integrating ChatGPT to provide natural language querying capabilities (we are think it's something that's going to get the whole community excited about)**. Specifically, users will no longer need to be proficient in SQL and can run queries using natural language prompts. + +We will introduce a P2P structure for storage nodes to make them decentralized. We also plan to optimize and upgrade the UI based on user feedback, such as adding more dashboards and improving the data creation process. Additionally, we will explore integrating Grafana for better data visualization dashboards. + +Lastly, we expect to collaborate with foundations to promote our platform and showcase its value to more users. We will also engage with the community through platforms such as Twitter, YouTube, Medium, and others to introduce hyperdot. + diff --git a/applications/ISO-8583-implementation.md b/applications/ISO-8583-implementation.md new file mode 100644 index 00000000000..1bd7f617d96 --- /dev/null +++ b/applications/ISO-8583-implementation.md @@ -0,0 +1,175 @@ +# ISO-8583 implementation + +- **Team Name:** Dastanbek Samatov +- **Payment Address:** 0xc42D0562BB4e53f5e9D888df35e1B91eA0f19cC3 (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +This application is in response to the [ISO-8583 RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_8583.md). + +### Overview + +ISO-8583 PoC implementation for Substrate. + +In this project I aim to implement the proof of concept for the ISO-8583 standard in Substrate. The implementation will be based on the extensive research done by [Adit Patel](https://github.com/adit313) in the following [repository](https://github.com/adit313/ISO8583-Blockchain-Integration-Plan). + +I've already worked on the similar project for [EBICS standard](https://github.com/element36-io/ocw-ebics). I can leverage the knowledge gained from that project and research done by Adit Patel to implement the ISO-8583 standard in Substrate. + +### Project Details + +To fully imitate the ISO-8583 standard, I have divided this PoC project into two parts: infrastracture and blockchain. Infrastracture components are responsible for imitating the flow of the ISO-8583 message from the merchant to the PCIDSS compliant gateway. Blockchain components are responsible for further processing of the ISO-8583 message and settling the transactions/messages on the Substrate chain. + +Below is the implementation plan in a deeper technical detail from Adit Patel's research: + +![Implementation plan](https://github.com/dastansam/Grants-Program/assets/88332432/8b832448-9095-4846-95ea-ccaebe5e52a5) + +#### Infrastracture + +For this part, the implementation will consist of the following components: + +- **Merchant**: A hybrid web application, i.e can be used to either make the payment directly on Substrate chain, guaranteeing instant settlement, or via debit/credit card. It will consist of a mock marketplace and main work will be done on the payment checkout window. Depending on the payment method, the application will then send the payment request to the corresponding payment processor. +- **Payment processor (Stripe, Visa, Mastercard)**: The payment processor will be imitated by a web server that will accept the payment request from the merchant, compose the ISO-8583 message and send it to the gateway. It will maintain the offchain ledger (database). +- **PCIDSS Compliant Gateway (Oracle Company)**: The gateway is the first part of the centralized oracle. It will be mocked by a message broker that will process the incoming ISO-8583 messages from the traditional network and pools them for the offchain worker to query. It is also responsible for maintaining an up-to-date record of the offchain and on-chain ledger, validating messages, keeping track of chain events and composing new messages in case there is a mismatch between the two ledgers. + +For the above componenets, there are already some open source projects that can be used. Namely: + +- [ISO-8583 implementation in Javascript](https://github.com/zemuldo/iso_8583): I will use this library in mock web server and the merchant application. Opted for this library since it seems to be well maintained and documented (the Rust version has the last commit from 2019). +- [RabbitMQ](https://www.rabbitmq.com/): I will use RabbitMQ as a message broker for the gateway. It is a well known and widely used message broker. It also has a [Rust client](https://github.com/jgallagher/amiquip) + +And for the merchant app, below are the mockups of payment checkout window: + +![Card payment](https://github.com/dastansam/Grants-Program/assets/88332432/ee5e870a-1992-4d74-b6da-288b615f50e2) + +![Payment on-chain](https://github.com/dastansam/Grants-Program/assets/88332432/f4412bf4-b2c3-4407-866a-6ebbd948ac35) + +![Successfull checkout](https://github.com/dastansam/Grants-Program/assets/88332432/64e6d9bc-54af-4848-a6db-226bc8eebd96) + +#### Blockchain + +On the blockchain side, there were three key components that were proposed in the research: + +- A centralized oracle +- ERC-20R smart contract +- Substrate chain + +However, from my previous experience building the EBICS PoC and generally as a more experienced Substrate developer, I believe the first two components can be simplified to: + +- **An offchain worker (OCW)**: It will act as a second part of the oracle, i.e it will query for the ISO-8583 messages from the gateway and will send them to the Substrate chain. The only way for the chain to receive the ISO-8583 messages will be through the OCW. This will ensure that the chain is not spammed with unnecessary messages and will also allow us to hide sensitive information like account numbers and authorization codes. +- **Pallet**: pallets are more flexible and a lot easier to implement and maintain than smart contracts. It will implement the ERC-20R standard and will settle the transactions on the Substrate chain. + +#### Challenges + +One of the main challenges for this project is the reversability of transactions in the ISO-8583 standard. The standard allows for the reversal of transactions in case of a dispute. This is not a problem for the traditional payment networks since they are centralized and can easily reverse the transaction. Although, ERC20-R standard has a `revert` function, it becomes complicated when we try to get back the funds that are already spent. I will have to do more research on this topic and will try to come up with a solution. + +#### Inspirations + +EBICS PoC implementation offers some insights and inspiration, however, the ISO-8583 standard is a lot more complex and will require a lot more robust and complex infrastructure. Similarly, on the blockchain side, the reversability of transactions will pose a great challenge. Therefore, large parts of the blockchain components will need to be rewritten from scratch or significantly refactored in best case. + +### Ecosystem Fit + +A quote from Adit Patel here: + +> Supporting international standards would smooth the connection between crypto and traditional financial institutions and is a [go to market strategy for several competing projects](https://www.cryptopolitan.com/iso-20022-compliant-crypto-list/). While those efforts are focused on the newer ISO-20022, not ISO-8583, there is significant value in being the first blockchain to support traditional banking infrastructure and dislodge incumbent networks such as SWIFT or Visa/Mastercard. + +## Team :busts_in_silhouette: + +### Team members + +- Dastanbek Samatov + +### Contact + +- **Contact Name:** Dastanbek Samatov +- **Contact Email:** dastanbeksamatov@gmail.com +- **Website:** https://dastansam.github.io/ + +### Legal Structure + +- **Registered Address:** No registred entity +- **Registered Legal Entity:** No registred entity + +### Team's experience + +Dastanbek Samatov is a Software Engineer with more than 3 years of experience. For the past 2 years he has been working as a Rust/Substrate Engineer focusing on parachain development and also has been involved with several Web3 Foundation grant projects in the past (some of them as lead developer): + +- `SCALE Codec in AssemblyScript` - https://github.com/LimeChain/as-scale-codec +- `Substrate Runtime in AssemblyScript` - https://github.com/LimeChain/as-substrate-runtime +- `Framework for Substrate Runtimes in AssemblyScript` - https://github.com/LimeChain/subsembly +- `OCW EBICS` - https://github.com/element36-io/ocw-ebics + +### Team Code Repos + +- https://github.com/subclone/iso-8583-chain-template +- https://github.com/subclone/payment-processor + +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/dastanbeksamatov + +### Team LinkedIn Profiles (if available) + +- https://linkedin.com/in/dastanbek-samatov + +## Development Status :open_book: + +This application is in response to the [ISO-8583 RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_8583.md). + +The implementation is inspired from the previous [research](https://github.com/adit313/ISO8583-Blockchain-Integration-Plan) project for this RFP. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 months +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 28,000 USD + +### Milestone 1 Infrastructure Part + +- **Estimated duration:** 2 month +- **FTE:** 1 +- **Costs:** 14,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can spin up the whole infrastructure components. | +| **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. | Merchant App | I will create a React application that will mock the merchant. The app will be connected to the Substrate chain with `PolkadotJs` and users will be able to directly pay using an on-chain extrinsic. Web app will also handle necessary balance checks by querying chain to early return invalid transactions. Users will also have an option to use their mock plastic cards. | +| 2. | Payment Processor | I will create a NodeJs server that will receive payment requests from merchant app, compose the ISO-8583 message and send it to the gateway. This server will also be responsible for keeping the offchain ledger, similar to how traditional networks currently operate. | +| 3. | PCIDSS Compliant Gateway | I will create a message broker service that will serve as a centralized oracle gateway. It will process and pool incoming messages from the mock payment processor. Oracle will maintain a constant connection to Substrate chain, to ensure the validity of messages in the pool before they are consumed. For example, if there is a transfer from Alice to Bob, oracle will ensure that `Alice` has enough funds both offchain and on-chain, `tx_id` of transfer is not already on-chain, etc. It will also include mechanisms to ensure the message is being consumed by genuine offchain worker and not some other malicious *consumer*. For this step, some basic cryptographic authentication method will be used. | +| 4. | Makefile | I will create a Makefile that will provide commands to ease testing, running and maintaining the project | + + +### Milestone 2 Blockchain Part + +- **Estimated Duration:** 2 months +- **FTE:** 1 +- **Costs:** 14,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| **0e.** | Article | I will publish an article that explains the complete lifecycle and future plans of the project | +| 1. | Substrate Chain | I will create a Substrate chain forked from `substrate-node-template`. | +| 2. | Offchain Worker | I will write an offchain worker logic that queries PCIDSS compliant gateway for ISO-8583 messages, processes them and dispatches extrinsics to the chain. | +| 3. | ERC-20R Pallet | I will create a pallet that implements the `ERC-20R` interface. It will be responsible for processing incoming message from the offchain-worker and PCIDSS compliant oracles. It will perform security checks, maintain the ledger and control the issuance of the tokens. | +| 4. | Integration tests | I will add end-to-end tests in Rust to illustrate full lifecycle of ISO-8583 transactions. | +| 5. | PCIDSS Oracle Gateway | I will enhance PCIDSS Oracle Gateway services to make it work with Substrate chain. This is essentially adding new service that monitors and reacts to certain events from Substrate chain. | +| 6. | Makefile | I will create a Makefile that will provide commands to ease testing, running and maintaining the project | + +## Future Plans + +In case of successful PoC, I plan to continue working on this project to address some of the pain points of the PoC: + +- **Reversability**: look for more decentralized ways to guarantee reversability of the transactions, maybe with somewhat similar mechanism to slashing +- **Decentralization of Oracles**: look for more decentralized ways of message processing by using decentralized oracles, maybe look for the direction of zero-knowledge proofs + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +I have previously worked on several grant projects (listed above) and generally have been in Polkadot ecosystem for more than 3 years. diff --git a/applications/ISO20022-Implementation-POC.md b/applications/ISO20022-Implementation-POC.md new file mode 100644 index 00000000000..2e598d39e93 --- /dev/null +++ b/applications/ISO20022-Implementation-POC.md @@ -0,0 +1,180 @@ +# ISO20022 Ecosystem Research and Technical Design + +- **Team Name:** Solidbit GmbH +- **Payment Address:** CHF (22 November, 2023, 08:57 UTC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + + +## Project Overview :page_facing_up: + +### Overview + +This proposal is a response to [this RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_20022.md). + + +ISO20022 is the future standard of financial transactions of all kinds including payments, foreign exchange and securities trading. Many blockchain ecosystems like [Ripple](https://ripple.com/), [Cardano](https://cardano.org/) and [Stellar](https://stellar.org/) are already ISO20022 compliant. In order to make Polkadot ISO20022 compatible as well, it is necessary to start designing how such an integration would look like in pratice. + +### Project Details + +If Polkadot wants to become compatible with the traditional finance industry, an ISO20022 integration will be the right place to start. +The goal of this project is to get an overview of how other blockchain ecosystems approach the ISO20022 integration, outline challenges and opportunities of such an integration and provide technical designs of how Polkadot could become ISO20022 compatible. + +## Team :busts_in_silhouette: + +### Team members + +- Piero Guicciardi (Project Lead & Developer) + +### Contact + +- **Contact Name:** Piero Guicciardi +- **Contact Email:** pg@solid-bit.com +- **Website:** https://solid-bit.com + +### Legal Structure + +- **Registered Address:** General Wille Strasse 99, CH-8706 Meilen, Switzerland +- **Registered Legal Entity:** Solidbit GmbH (CHE-267.620.734) + +### Team's experience + +Piero has been a core protocol developer for [Encointer](https://github.com/encointer) for the last two years, has recently become a member of the Polkadot Technical Fellowship and was granted a [W3F Grant](https://github.com/w3f/Grants-Program/pull/2123). + +Below you can find a list of contributions by Piero: + +#### Big Tip for LiteScan +- Referenda: https://polkadot.polkassembly.io/referenda/970 +- Repo: https://github.com/pifragile/litescan + + +#### W3F Grant Democratic Governance +- Application: https://github.com/w3f/Grants-Program/pull/2123 +- Submission: https://github.com/w3f/Grant-Milestone-Delivery/pull/1101 + +#### Encointer core protocol: +- Design and implement faucet + - https://github.com/encointer/book/pull/14 + - https://github.com/encointer/encointer-node/pull/333 + - https://github.com/encointer/pallets/pull/319 + - https://github.com/encointer/pallets/pull/326 + - https://github.com/encointer/encointer-parachain/pull/193 +- Design and implement democracy module + - https://book.encointer.org/protocol-democracy.html + - https://github.com/encointer/pallets/pull/273 +- Redesign participant attestations + - https://github.com/encointer/pallets/pull/231 + - https://github.com/encointer/pallets/issues/215 +- Endorsement after registration + - https://github.com/encointer/pallets/pull/202 +- Early reward payout + - https://github.com/encointer/pallets/pull/233 +- Allow for upgrading registrations and unregistering + - https://github.com/encointer/pallets/pull/254 +- Allow reputables to endorse + - https://github.com/encointer/pallets/pull/268 +- Geohash location validation algorithm + - https://github.com/encointer/pallets/pull/55 +- Constant time random permutation for meetup assignment + - https://github.com/encointer/pallets/pull/68 + +#### Misc: +- Implement custom RPCs + - https://github.com/encointer/pallets/pull/196 +- Implement storage migrations for Weight V2 + - https://github.com/encointer/pallets/pull/308 +- Various polkadot/substrate dependency bumps + - https://github.com/encointer/pallets/pull/299 + - https://github.com/encointer/encointer-parachain/pull/171 +- Fee payment in Encointer community currency + - https://github.com/encointer/encointer-node/pull/194/files + - https://github.com/encointer/encointer-node/pull/226 + - https://github.com/encointer/pallets/pull/190 +- Integrate try runtime + - https://github.com/encointer/encointer-parachain/pull/177/files + - https://github.com/encointer/encointer-node/pull/312/files + + +#### Non rust contributions: +- Build an indexer using qubquery + - https://github.com/encointer/subquery (Main author) +- Build an accounting tool for encointer businesses + - https://github.com/encointer/accounting-frontend (Main author) + - https://github.com/SolidbitGmbH/encointer-accounting-backend (Main author) +- Build an integration for Encointer personhood in KILT + - https://github.com/encointer/kilt-personhood (Main author) +- Contributions to encointer js + - https://github.com/encointer/encointer-js/pull/78 + + +Piero has previously received a W3F grant for a different project(see above). + + +### Team Code Repos + +- https://github.com/pifragile +- https://github.com/SolidbitGmbH + +Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. + +- https://github.com/pifragile + + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/piero-guicciardi-66b939152/ + + +## Development Status :open_book: +This project has not started yet, but there has been some previous related work in the ecosystem (see references), which we studied and will build upon. + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Estimated duration:** 1 month +- **FTE:** 0.25 (5 person days) +- **Total Costs:** 5200 CHF (5850 USD) + + + +### Milestone 1 — Ecosystem Research and Technical Design + +- **Estimated duration:** 1 month +- **FTE:** 0.25 (5 person days) +- **Costs:** 5200 CHF (5850 USD) + + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0c.** | Methodology | Description of how the information was sourced. | +| **0e.** | Bibliography | List of sources | +| 1. | Article | We will publish an **article** that outlines the current state of other blockchain's ISO20022 development as well as technical designs how to solve this for Polkadot.| + +## Future Plans + +The next step will be to implement a POC of the proposed soution. + +## References +- [ISO 20022 Message Catalogue](https://www.iso20022.org/iso-20022-message-definitions?business-domain=1) +- [Nice website describing payment flows](https://www.iso20022payments.com/) +- [Book ISO20022 For Dummies](https://www.swift.com/campaign/iso-20022/iso-20022-dummies) +- [ISO20022 example messages](https://developer.gs.com/docs/services/transaction-banking/pain001sample/) + +### Previous Related W3F Grants + +ISO20022 Research: +- https://github.com/w3f/Grants-Program/blob/master/applications/ISO20022.md +- https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/ISO20022-milestone1.md + + +ISO8583 Research: +- https://github.com/w3f/Grants-Program/blob/master/applications/Integrating-ISO8583.md +- https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/ISO8583-milestone-1.md + + +ISO8583 Implementation: +- https://github.com/w3f/Grants-Program/pull/2184 +- https://github.com/w3f/Grants-Program/pull/1809 +- https://github.com/w3f/Grants-Program/blob/master/applications/ISO-8583-implementation.md +- https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/iso_8583_PoC_milestone_1.md diff --git a/applications/ISO20022.md b/applications/ISO20022.md new file mode 100644 index 00000000000..50e1bb7d190 --- /dev/null +++ b/applications/ISO20022.md @@ -0,0 +1,171 @@ +# ISO20022 PoC + +- **Team Name:** Open Smart Contract +- **Payment Address:** 3GTe5ArJLC8jesr6UFtB9kcoguQmvo8Cuo (BTC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + + +## Project Overview + +Response to [RFP 20022](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/ISO_20022.md) + +Cross-border payment example as proof of concepts, leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/v3/concepts/off-chain-features/) that show the advantages of using [ISO20022](https://www.iso20022.org/) together with Substrate. + +### Overview +The project is an [ISO20022](https://www.iso20022.org/) based cross-border payment proof of concepts implemented with Substrate off-chain computation and indexed data storage. + +ISO (International Organization for Standardization) 20022 is becoming the de facto global data standard for payments and electronic data interchange already adopted by many countries. However the ISO20022 are all about centralized fiat based payment rails among privileged global financial institutions. + +Blockchain based decentralized payment solutions can provide efficiency, low latency and cost savings potentially benefiting billions of users worldwide. There are ledger based currency exchange and remittance network such as the real-time gross settlement system from Ripple Labs Inc. yet it is permissioned, centralized and not capable of cross chains. + +Polkadot, with its multi-chain architecture, security and cross chain interoperability, is uniquely positioned to support ISO20022 compliant global payments. This project is a Proof of Concepts to understand what it takes for Dotsama ecosystem to support a cross-border payment use case, leveraging on XCM, OCW and Substrate pallets, challenges and recommendations. + + +### Project Details + +- Mockups/designs of any UI components + - Use Contracts-UI (or Polkadot.js) UI interface to interact with deployed smart contracts + +- Data models / API specifications of the core functionality + - ISO20022 XML data models that captures essential ISO20022 cross-border payment metadata + - ISO20022 data types to XCM mappings with custom data types if gaps + - Data securely stored off chain, indexed for queries + - ISO20022 messaging and payment events and stats + - Persisted off chain data storeage fo performance benchmarks, throughput, gas fees, binary size, payment latency and costs + +- An overview of the technology stack to be used + - Substrate off chain workers to process compute intensive tasks such as ISO20022 message wrangling + - Substrate off chain storage / indecing to persist string heavy ISO20022 messages + - ISO20022 messages parsing / mapping / processing using OCWs + - Substrate XCM frame pallet with transport methods for ISO20020 messaging + - Custom OCWs to support cross-border payment use case with message, events, stats and payment flow query capabilities + - Optional off chain connected cloud storage and HTTP requests +- Documentation of core components, protocols, architecture, etc. to be deployed + - Published article documenting detailed analysis of what it takes to support ISO20022 compliant cross-border payments on Dotsama blockchains + - Custom pallet(s) implementing cross-border payment logic + - Off chain worker logic processing compute and storage intensive payment processings + - Mapping from cross-border ISO20022 messages to XCM and XCMP messaging + - ISO20022 messages, payment history, events and stats, stored off chian with indexes for queries + - Gaps identified and solution recommendations + - Substrate based Dotsama blockchain as testnet to deploy sandbox +- PoC/MVP or other relevant prior work or research on the topic + - Our research shows that many challenges exist to support ISO20022 compliant cross border payment use case + - A traditional ISO20022 cross border payment means multiple transactions in various ISO20022 message types, with multiple hops among financial entities inter-connected via custom agreements / fee structures / sfovereign regulations, with no standards + - ISO20022 and XCM are at different granularies with a single cross-border payment mapping to a set of XCM messages with flow logic + - ISO20022 payment transactions have different fees / charges based on many factors + - Traditional cross-border payments on fiat rails do not have blockchain "gas fee" concept + - Data type incompatibilities between IS20022 and XCM, such as date and time, currency, float, array, etc. + - No out of box support of XML data processing and mapping such as XSD transformations + - No native foreign exchange / currency conversion support + - XCVM with instruction set for XCMP messaging is a totally different paradigm as compared to traditional message passing + - No existing gas light solution to handle compute intensive and indexable data storage for off chain payment processing + +- What your project is _not_ or will _not_ provide or implement + - This is not a complete cross border payment system given the scope of proof of concepts + - Likely this is the first ISO20022 project on Dotsama, there could be unexpected gaps discovered + - This project is not a full blown IS20022 implementation on Dotsama / Substrate but explore to expose gaps for future endeavors + - This project is not about payment identity / KYC / AML solutions + - This milestone is all about understanding what it takes to support ISO20022 compliant cross-border payments on Dotsama, not implementations which could come later with more clarity coming out of this project + +### Ecosystem Fit + +- Where and how does your project fit into the ecosystem? + - According to the RDP: "The goal of this RFP is to find teams that implement tools that make it easy and possible for the traditional finance industry to leverage Substrate and ink! smart contracts to interact with ISO 20022 in various ways" +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? + - Targeting ecosystem developers to leverage on the learning and tools to further develop ISO20022 compatible dApps, to make it possible for transitional financial institutions to interoperate with Polkadot / Kusama / Substrate blockchains based payment apps. +- What need(s) does your project meet? + - Explore possibilities and gaps of Polkadot / Substrate support of ISO20022 standard for future improvements +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? + - If so, how is your project different? + - If not, are there similar projects in related ecosystems? There are known blockchains already claim to support ISO20020 such as Ripple XRP, XLM, Algorand, etc. + +## Team + +### Team members + +- Name of team leader: Daniel Deng +- Consultants with ISO20022 and cross-border domain expertise + +### Contact + +- **Contact Name:** Daniel Deng +- **Contact Email:** OpenSmartContract@gmail.com + +### Legal Structure + +- **Registered Address:** No registred entity +- **Registered Legal Entity:** No registred entity + +### Team's experience + +Daniel is the Chief Product Officer at HeroDAO where he has led blockchain based smart contract products and development on Polkodot / Kusama blockchains. Previously at Meta he managed crypto (Libra / Diem) and fiat payments and web3 initiatives. Prior to that, he was Senior Director of Product Management at Visa managing Visa's global payment product portfolios and platforms. + +The project to add consultants from fintech / banks / financial institutions with relevant domain expertise in ISO20022 and cross-border payments. + +Here's a recent [Medium article](https://medium.com/@opensmartcontract/learn-ink-by-example-order-food-on-blockchain-a4024b2dee4a) on ink! smart contract with Rust macros implementing dApp on Dotsama chain, with [Smart Contract Deployment and Interaction Guide using Contracts-UI and Polkadot.js](https://github.com/InkSmartContract/BlockchainFoodOrder/blob/main/BlockchainFoodOrder%20Smart%20Contract%20Deployment%20and%20Interactions%20Guide.pdf). + +### Team Code Repos +- [Order Food on the Blockchain](https://github.com/InkSmartContract/BlockchainFoodOrder) + +Please also provide the GitHub accounts of all team members. +- [GitHub1](https://github.com/OpenSmartContract) +- [Github2](https://github.com/FPLeader) + +### Team LinkedIn Profiles (if available) +- [Profile](https://www.linkedin.com/in/dengdaniel) + +## Development Status + +- [Blockchain Food Order dApp](https://github.com/InkSmartContract/BlockchainFoodOrder/blob/main/Learn%20ink!%20by%20Example%20%E2%80%94%20Order%20Food%20on%20the%20Blockchain.pdf) +- [Smart Contract Deployment and Interaction Guide using Contracts-UI and Polkadot.js](https://github.com/InkSmartContract/BlockchainFoodOrder/blob/main/BlockchainFoodOrder%20Smart%20Contract%20Deployment%20and%20Interactions%20Guide.pdf) + +## Development Roadmap + +### Overview + +- **Estimated duration:** ~1-2 months +- **FTE:** 1,2 +- **Costs:** 25K USD + +### Milestone 1 + +- **Estimated duration:** ~1-2 months +- **FTE:** 1,2 +- **Costs:** 25K USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | Design documents with details on what it takes for Polkadot/Substrate to support ISO20022 messages, gaps and solution recommendations | +| 1. | Design the use case | Design an ISO20022 cross border payment use case with persona, end-to-end flow | +| 2. | Identify ISO20022 message types and examples for X-border payment | Specify all ISO20022 message types with examples for cross border payment, including reference data fields | +| 3. | Map ISO20022 - XCM messages | Map ISO20022 cross-border payment message types to a set of XCM messages with processing logic, including identifying data type incompatibilities between IS20022 and XCM, replacement data types and necessary XML transformations | +| 4. | Map ISO20022 - XCMP | Map ISO20022 cross-border payment messageing to XCMP for cross parachains transport| +| 5. | Specify off chain data storage | Specify off chain data structure, storage and indexes for ISO20022 messages, payments, events, stats| +| 6. | Specify off chian worker logic | Specify OCW logic for ISO20022 message processing, payment flow, error handling| +| 7. | Specify Substrate pallets | Specify custom pallet(s) to implement X-border payments and OCW integrations| +| 8. | Recommend blockchain gas fees handling in ISO20022 framework | Recommend solution how to fulfill blockchain gas fees in ISO20022 framework | +| 8. | Recommend how to implement ISO20022 cross-border charges & fees | Recommend solution how to implement ISO20022 cross-border payment inter-bank / X-border payment charges and fees | +| 9. | Specify query of ISO20022 messages and transactions | Specify query interface to retrieve selected ISO20022 messages and transactions| +| 10. | Publication to share with the broader community and get additional feedback | Medium article covering: 1) feasibility and comparative advantages of Substrate based ISO20022 compliant cross-border payments on Dotsama chain; 2) benefits of such a solution in contrast to traditional centralized cross-border payments; 3) recommendation of future works towards a scalable, performant and cost effective solution supporting ISO20022 on Polkadot/Kusama chains and beyond. | + +## Future Plans + +- Publish learning and share with the community, similar to this [ Medium article](https://medium.com/@opensmartcontract/learn-ink-by-example-order-food-on-blockchain-a4024b2dee4a) and/or [Contracts-UI and Polkadot.js Smart Contract Deployment and Interaction Guide](https://github.com/InkSmartContract/BlockchainFoodOrder/blob/main/BlockchainFoodOrder%20Smart%20Contract%20Deployment%20and%20Interactions%20Guide.pdf) +- Long term we intend to expand this ISO20022 PoC to: + - develop reusable tools / features to bring ISO20022 compliant payments to the Dotsama ecosystem + - Bring Polkadot / Kusama chains up to speed with Ripple XRP / XLM / Algorand / etc. on ISO20022 support + - Onramp transitional financial institutions worldwide to blockchain enabled cross border payments + - Leverage Dotsama's unique off chain computing, storage and connections (cloud, HTTP) capabilities to scale web3 dApps + - Support ISO20022 MX messages via Polkadot XCMP, and possible integration with IBC (Inter-Blockchain Communications) + - Future milestones implementing the use case with workload estimation with insights from this initial milestone + +## Referral Program (optional) + +You can find more information about the program [here](../README.md#moneybag-referral-program). +- **Referrer:** N/A +- **Payment Address:** N/A + +## Additional Information + +**How did you hear about the Grants Program?** Web3 Foundation Website and previous work interactions diff --git a/applications/Idavoll Network.md b/applications/Idavoll Network.md index a2610174b1a..2f6e567743e 100644 --- a/applications/Idavoll Network.md +++ b/applications/Idavoll Network.md @@ -1,10 +1,9 @@ -# Open Grant Proposal +# Idavoll Network -* Project: Idavoll Network * Proposer: [jasonberger0](https://github.com/jasonberger0) * Payment Address: 1NNtuqwroKc9cMZdigpLdNLrzPKCp7zkXT -## Project Overview : +## Project Overview ### Overview @@ -22,30 +21,29 @@ Idavoll Network has a set of pallets to achive the management of DAOs: orgnaizat #### Transfer Assets -+ the Organization members initiate a proposal to transfer organizational assets through the Finance Module. The proposal is confirmed on the Vote Module and required to complete the voting results of the organization members within a certain period of time. The voting results are required to meet the asset transfer rules in the Finance Module. The approval votes are greater than the minimum approval votes. Only after the number and the number of negative votes are less than the limit of the maximum number of negative votes, can the proposed movement of asset transfer within the organization be realized through the Finance Module. +* the Organization members initiate a proposal to transfer organizational assets through the Finance Module. The proposal is confirmed on the Vote Module and required to complete the voting results of the organization members within a certain period of time. The voting results are required to meet the asset transfer rules in the Finance Module. The approval votes are greater than the minimum approval votes. Only after the number and the number of negative votes are less than the limit of the maximum number of negative votes, can the proposed movement of asset transfer within the organization be realized through the Finance Module. #### Snapshot Vote Decisions -+ We can combine the organization module, voting module and token module to implement the decision management process. Users can create any proposal (an easy-to-understand term that the proposal must follow) and initiate the voting process. All users holding the corresponding tokens can participate in the voting. The voting ends, the Idavoll Network will count the voting results of the voters according to the snapshot of the current blockchain state. The voting results will be used as a community consensus and will be permanently stored on the blockchain. +* We can combine the organization module, voting module and token module to implement the decision management process. Users can create any proposal (an easy-to-understand term that the proposal must follow) and initiate the voting process. All users holding the corresponding tokens can participate in the voting. The voting ends, the Idavoll Network will count the voting results of the voters according to the snapshot of the current blockchain state. The voting results will be used as a community consensus and will be permanently stored on the blockchain. ## Team :busts_in_silhouette: ### Team members -+ jasonberger0 -+ Dylan -+ kericfrank +* jasonberger0 +* Dylan +* kericfrank ### Team’s experience -+ jasonberger0 Over 10 years of experiences in Development and Management,real time database products and digital currency transaction platform products expert. Currently focused on Blockchain Development and Cross-chain Technologies. -+ Dylan holds a master degree from Tsinghua University. He has more than 10 years of experience inlarge-scale computing and algorithm, with many patents such as consensus algorithm and blockchain transaction. -+ kericfrank: 8+ years development experience, proficient in public chain and cross chain development, proficient in using go and rust, p2p network expert. - +* jasonberger0 Over 10 years of experiences in Development and Management,real time database products and digital currency transaction platform products expert. Currently focused on Blockchain Development and Cross-chain Technologies. +* Dylan holds a master degree from Tsinghua University. He has more than 10 years of experience inlarge-scale computing and algorithm, with many patents such as consensus algorithm and blockchain transaction. +* kericfrank: 8+ years development experience, proficient in public chain and cross chain development, proficient in using go and rust, p2p network expert. ### Team Code Repos -* https://github.com/idavollnetwork +* https://github.com/idavollnetwork ## Development Roadmap :nut_and_bolt: @@ -75,6 +73,6 @@ In this milestone, We will implement Idavoll DAO proof-of-concept. ## Future Plans -+ we will provides a Dapp for everyone to interact with the Idovall network. +* we will provides a Dapp for everyone to interact with the Idovall network. -+ In the future, the Idavoll Network will add a court protocol to resolve subjective disputes with binary outcomes, combined with the use of IDV’s infrastructure, so that the DAOs can create proposal agreements that define the subjective constraints of organizational operations, and can be used by a minority of interests Stakeholder implementation. \ No newline at end of file +* In the future, the Idavoll Network will add a court protocol to resolve subjective disputes with binary outcomes, combined with the use of IDV’s infrastructure, so that the DAOs can create proposal agreements that define the subjective constraints of organizational operations, and can be used by a minority of interests Stakeholder implementation. diff --git a/applications/Integrating-ISO8583.md b/applications/Integrating-ISO8583.md new file mode 100644 index 00000000000..176e3caab06 --- /dev/null +++ b/applications/Integrating-ISO8583.md @@ -0,0 +1,119 @@ +# Integrating ISO-8583 + +> This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. +> +> See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. + +- **Team Name:** Stardust Labs Inc. +- **Payment Address:** 0xF3d5F194D9eF961a85a4d5be05EFda7B2B33005d (DAI, Ethereum Mainet) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +> ⚠️ _The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe._ + +## Project Overview :page_facing_up: + +### Overview + +- A brief description of your project. + +This proposal is in [response to the ISO-8583 RFP, that aims to make it easy and possible for the traditional finance industry to leverage substrate and ink! smart contracts to interact with ISO 8583 in various ways](https://github.com/w3f/Grants-Program/blob/master/rfps/open/ISO_8583.md). While it seems the original RFP was primarily for a straightforward techincal implementation, the actual implementation of ISO-8583 on a distributed, permissionless architecture has several unsolved challenges. This grant proposal is to research and develop acceptable solutions to those challenges or at the very least provide the Web3.0 Foundation with a comprehensive view of the options and tradeoffs. + +- An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama. + +Supporting international standards would smooth the connection between crypto and traditional financial institutions and is a [go-to-market strategy for several competing projects](https://www.cryptopolitan.com/iso-20022-compliant-crypto-list/). While those efforts are focused on the newer ISO-20022, and not ISO-8583, there is significant value in being the first blockchain to support traditional banking infrastructure and dislodge incumbent networks such as SWIFT or Visa/Mastercard. + +- An indication of why your team is interested in creating this project. + +I've built credit card infrastructure before during my role as an analyst at Capital One and believe I can bring some experience from traditional finance to this problem. At the very least I can call out the details and complex logistics that others without might miss. + +### Project Details + +[ISO-8583](https://en.wikipedia.org/wiki/ISO_8583) is the international standard for card based payments and transactions. It's used everywhere from ATMs to Merchant point of sale terminals. Supporting international standards could help smooth the connection between crypto and traditional financial institutions. [Further simplifying matters is](https://crates.io/crates/iso8583) [that several rust crates exist](https://github.com/rkbalgi/iso8583_rs) [supporting the packing and unpacking of ISO-8583 data streams.](https://docs.rs/i8583/latest/i8583/) + +At first glance, it seems like one could easily just integrate these packages to achieve the goals of the RFP, namely: + +- (Java) APIs or packages that make it possible for the traditional finance industry to integrate a substrate-based ISO 8583 solution into their existing tech stack. +- Proof of concepts, potentially leveraging the unique [Off-Chain Features of Substrate](https://docs.substrate.io/v3/concepts/off-chain-features/) that show the advantages of using ISO 8583 together with Substrate. +- Efficient on-chain representation of the ISO 8583 syntax + +Unfortunately, the logistics of actually implementing ISO-8583 compliant infrastructure on blockchains is unintuitvely complex. At a minimum, 3 major issues exist that must be addressed. + +**Security** +ISO-8583 datastreams [reveal far too much information to ever be publically exposed](https://neapay.com/post/iso8583-atm-pos-crypto-api-integration-coinbase-binance_102.html). Here neapay proposes using ISO-8583 to connect to Coinbase to purchase crypto. However you can see that once the datastream is unpacked, the user's financial details are immediately revealed. Unpacking data is a trivial process that has no security, ISO-8583 data is not encrypted. Of note is the exposed primary account number (F02_PAN: 9876 5000 0030 6082). Most people would recognize this number faster as their credit card number. While it is possible, and implemented in practice, to transfer the data securely between two, trusted centralized servers using [Diffie Hellman key exchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), research is needed to construct a way to place ISO-8583 data on-chain securely, if it is even possible. There are also laws about retaining this information for a fixed period of time, for example, [Minnesota, a US state mandates that this information is deleted within 48 hours of reciept](https://www.revisor.mn.gov/statutes/cite/325E.64) which is at odds with the enduring, provable structure of a blockchain. + +**Transaction Reversals** +Outside of simple purchases, one of the most common messages communicated over ISO-8583 are [chargebacks.](https://en.wikipedia.org/wiki/Chargeback) [About 0.6% of all transactions are ultimately recalled, though it varies by industry.](https://shiftprocessing.com/chargeback-statistics/) ISO-8583 was designed to handle this process seamlessly and has a reserved MTI code for all chargebacks and reversals (x4xx). Unfortunately, modern blockchains by design are irreversible. From the original [introduction of Satoshi Nakamoto's white paper](https://bitcoin.org/bitcoin.pdf). +> While the system (traditional finance) works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. + +Supporting ISO-8583 functionality would require building a new token standard, or making changes to the operation of the blockchain to allow reversible transactions. A solution highlighted in the original bitcoin white paper is automatic escrow accounts, but research would be needed to identify the best way to implement these accounts or if there are better solutions. + +**Authorizations and Privilages** +This leads to another major challenge. In traditional banking, the users are not equal. Certain entites such as the issuing bank or network can make decisions unilaterally without recourse. An example of this would be the aforementioned chargeback or transaction reversals which can be performed by the issuing bank or network for any reason. Blockchains operate on an equivalent peer model, and it is an open question as to how to authorize a super user and who should maintain super user priviliages over the entire network. + +For Milestone 1 we aim to deliver a robust implementation proposal with solutions to these challenges. While likely no the intent of the RFP, significant foundational reserach has to be done into the feasibility of integrating ISO-8583 with Substrate (or even blockchains in general). These challanges have significant risks and may prove unfeasible. For example, it is possible that it is ultimately too risky to store ISO-8583 data on-chain or even expose it to nodes. While we do not aim to make such determinations during Milestone 1, we will provide a detailed documentation of the major challenges, options for addressing these challenges, and the major tradeoffs. We will also try to summarize what others have done in this space. + +### Ecosystem Fit + +Supporting international standards would smooth the connection between crypto and traditional financial institutions and is a [go to market strategy for several competing projects](https://www.cryptopolitan.com/iso-20022-compliant-crypto-list/). While those efforts are focused on the newer ISO-20022, not ISO-8583, there is significant value in being the first blockchain to support traditional banking infrastructure and dislodge incumbent networks such as SWIFT or Visa/Mastercard. + +## Team :busts_in_silhouette: + +### Team members + +- Adit Patel + +### Contact + +- **Contact Name:** Adit Patel +- **Contact Email:** adit.patel@stardustfunds.com +- **Website:** https://stardust.finance/ + +### Legal Structure + +- **Registered Legal Entity:** Stardust Labs Inc. is a registered C-corp incoporated in Wyoming + +### Team's experience + +Adit is a technical expert on cryptography, distributed ledgers, financial markets, and new product development. He graduated Columbia in 2011 with a BSc in Applied Physics and a minor in Econ. During his time there, he took additional coursework focused on cryptography, statistics, and fundamental computer science. After graduating, he joined Capital One and quickly rectified the failing, newly launched small business brand. These efforts made him well known as the go-to analyst for successful new product development, strategy and launch. He was tapped to design and launch financial products for Hispanic consumers and tapped again to build Capital One’s B2B financial products. During his tenure there, Adit experienced first hand the hard learnings that lead to efficient risk mitigation in financial products and the intricacies of financial engineering. He has a decade of technical experience at the intersection of finance and technology and has built and implemented financial products including credit cards before. + +### Team Code Repos + +- https://github.com/adit313/ + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/adit-patel/ + +## Development Status :open_book: + +- link to RFP: https://github.com/w3f/Grants-Program/blob/master/rfps/open/ISO_8583.md + +## Development Roadmap :nut_and_bolt: + +Through this grant proposal, we aim to provide a well-detailed analysis and implementation plan for incorporating ISO-8583 with Substrate. + +### Overview + +- **Total Estimated Duration:** 4 Weeks +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 10K + +### Milestone 1 — ISO-8583 Implementation Plan Research + +- **Estimated duration:** 4 Weeks +- **FTE:** 1 +- **Costs:** 10k USD + +| Number | Deliverable | Specification | +| ------: | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| 0. | Rights | All developed materials will be publicly accessible and public domain. | +| **1.** | Research Goal | A well-detailed analysis and implementation plan for incorporating ISO-8583 with Substrate with solutions or options for the outstanding challenges. | +| **1a.** | Specific Coverage | We will deep dive into the outstanding challenges related to security, reversibility, and authorization. As part of this, we will cover some industry security standards such as PCIDSS compliance and it's applicability, though this is not legal advice or intended to be legal advice. For each of these three challenges we will attempt to provide either a well developed solution or options with careful detailed tradeoffs for the Web3.0 Foundation team to select from. | + +## Future Plans + +- We think it is more important at this stage to have a robust implementation plan before attempting to build. If the plan is feasible and acceptable to the Web3.0 team, we will follow up with another grant for implementation. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** [Previous Grantee](https://github.com/adit313/Grants-Program/blob/master/applications/stardust.md) diff --git a/applications/Interstellar-Network.md b/applications/Interstellar-Network.md index f1a0f0c9a7f..eab1ef9bafe 100644 --- a/applications/Interstellar-Network.md +++ b/applications/Interstellar-Network.md @@ -1,81 +1,61 @@ -# W3F Grant Proposal - +# Interstellar - Wallet Phase 1 > > See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. -- **Project Name:** Interstellar - Wallet Phase 1 - **Team Name:** Interstellar - **Payment Address:** Ethereum - 0xc5C54DcD7b76b3B26ab4a02f191338F31aD732f6 (ETH) -- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview :page_facing_up: - - ### Overview - “The blockchain ecosystem needs an easy to use interface with hardware wallet security to reach the mass market.” - + The main pain points of non-custodial wallet solutions still are: + - **User experience** [Can an easy to set-up wallet be an efficient customer acquisition tool for DeFi players?](https://medium.com/@jlleleu/can-be-an-easy-to-set-up-wallet-an-efficient-customer-acquisition-tool-for-defi-players-8600812fe01e) -- **Security** [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) +- **Security** [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) > We think that current wallet solutions slow down the DeFi adoption. - Interstellar is a novel non-custodial peace of mind mobile wallet with a hardware security level. Based on a Substrate blockchain and SubstraTEE/IntegriTEE workers. **We can now provide the same hardware security level as hardware wallets with only a mobile and a blockchain** ![Grant-Scheme-White (1)](https://user-images.githubusercontent.com/4605611/145108720-becb76be-6c16-46c8-af69-7e953e5a166d.png#gh-dark-mode-only) - - - ![Grant-Scheme-Black (3)](https://user-images.githubusercontent.com/4605611/145108818-6f8b6158-6c27-4f0d-a104-9d2469c73636.png#gh-light-mode-only) - - **Thanks to Trusted User Interface TUI on mobile and Trusted Execution Environment on both mobile and blockchain nodes** Because TUI is not yet avalaible on all mobile devices we use a Garbled Circuit/Visual Cryptography scheme which provides an alternative that will be complementary down the road to mitigate potential flaws in TUI. - - - ![Iphone-Android-TUI-White (1)](https://user-images.githubusercontent.com/4605611/145201585-5d106219-e51e-44d3-8c1b-95fe99e71455.png#gh-dark-mode-only) ![Iphone-Android-TUI-Black (1)](https://user-images.githubusercontent.com/4605611/145201886-30bafb07-fc1c-4dc0-acf9-f0e9f163fa66.png#gh-light-mode-only) +#### Features - - - - -#### Features: - **Hardware security Level** - TEE on nodes and mobiles (incl. TUI), garbled circuits and visual cryptography secure interface - **Just download an app** - no registration, PIN, password, passphrase, private key or any secret to store or remember - **Multichain Wallet** - securely store and interact with native cryptocurrency coins and tokens from multiple blockchains - **Confirm a transaction with ONLY ONE SCREEN** - no SMS to wait for, no additional 2FA app to use, no QR code to scan -- **Up to 1,000,000 tps** - no tps limit due to slow consensus, thanks to IntegriTEE layer 2 based on hardware enclave technology -- **Social Recovery Service** - leverages the existing Substrate pallet and a novel decentralized autonomous recovery service +- **Up to 1,000,000 tps** - no tps limit due to slow consensus, thanks to IntegriTEE layer 2 based on hardware enclave technology +- **Social Recovery Service** - leverages the existing Substrate pallet and a novel decentralized autonomous recovery service + > We hope that we will be able to provide a response to the related RFP in the following phases -- **Features to securely send coins with social network messages (even to persons with no-wallet)** - explained in [Can an easy to set-up wallet be an efficient customer acquisition tool for DeFi players?](https://medium.com/@jlleleu/can-be-an-easy-to-set-up-wallet-an-efficient-customer-acquisition-tool-for-defi-players-8600812fe01e) +- **Features to securely send coins with social network messages (even to persons with no-wallet)** - explained in [Can an easy to set-up wallet be an efficient customer acquisition tool for DeFi players?](https://medium.com/@jlleleu/can-be-an-easy-to-set-up-wallet-an-efficient-customer-acquisition-tool-for-defi-players-8600812fe01e) -#### Our solution is designed to support blockchain and DeFi mass market adoption with: +#### Our solution is designed to support blockchain and DeFi mass market adoption with - **A decentralized key & asset management service** where the user’s privates keys and signature programs are stored and executed in TEE nodes - **A decentralized Trusted Transaction Validation protocol** that leverages TEE and TUI features on mobile, combined with One Time Garbled Circuits and Visual Cryptography to provide a **Trusted Authentication and Trusted UI layer** on user devices - - - - -The **Interstellar - Wallet Phase 1** W3F Grant Proposal focuses on two of the core components of the Interstellar solution: +The **Interstellar - Wallet Phase 1** W3F Grant Proposal focuses on two of the core components of the Interstellar solution: - A Substrate Off-Chain Worker OCW Garbled Circuit Factory GCF to manage an external garbled circuit generator service (designed to be used by Substrate developers regardless of the Interstellar solution) - An implementation of the Trusted Transaction Validation protocol in Substrate pallets to demonstrate the usage of GCF within a Substrate framework and with a mobile Garbled Circuit evaluator client @@ -87,21 +67,17 @@ Following are other use cases of the Garbled Circuit Factory: - Proof of history of legitimate computation with reusable Garbled Circuit (Interstellar ongoing research: Detection of adverse code execution during short transaction sessions - work in progress) - Post Quantum encryption and signature scheme implementations (NIST candidate examples) - ### Project Details - #### [Detailed documentation](https://docs.google.com/document/d/1RTPx4EeA0Ek33f-8_Dj7p-qjzBp6VqLrrXNhIrwvFWI/edit?usp=sharing) on the project - **OCW Garbled Circuit Factory** - **Transaction Validation protocol pallets (including mobile registry)** - **Transaction Validation Screen Technology (Trusted/Secure UI)** - - **Mobile client GC evaluator** - - - + - **Mobile client GC evaluator** #### Garbled Circuit Factory **previous work** + The team has already developed a strong authentication solution with circuits based on JustGarble implementation https://cseweb.ucsd.edu/groups/justgarble/ that we customized with Free XOR and Half Gates and other specific improvements for our needs (pre-computation of our Visual Cryptography Circuits). We achieved a production ready platform with significant performance on the logic circuit and garbled circuit production with AES-NI. The whole pipeline uses optimized memory management and avoids serialization/deserialization of the different circuit formats: HDL->non-garbled->garbled. @@ -114,18 +90,16 @@ We achieved a production ready platform with significant performance on the logi 4 circuits_per_hour : 639975 ``` - ![1844c95c-1b74-4987-8466-4ba14da41ff3 (Custom)](https://user-images.githubusercontent.com/4605611/141327055-ea10f548-d6d2-4b1a-af2e-a059f2f67673.png) - - ``` 5,65 ms per circuits on a Processor 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz, 2304 Mhz, 8 Core(s), 16 Logical Processor(s) ``` - -------------------------- + #### Technology stack + - VHDL - C/C++ - Java/Kotlin/Swift @@ -133,12 +107,6 @@ We achieved a production ready platform with significant performance on the logi - Rust/Substrate - IPFS - - - - - - ### Ecosystem Fit > Where and how does your project fit into the ecosystem? @@ -146,15 +114,10 @@ We achieved a production ready platform with significant performance on the logi This project is the first phase of a wallet project. Although, we think that our Trusted Transaction Validation protocol could bring a novel approach to address UX/UI security issues regardless of other features of our frictionless wallet. We designed our validation transaction protocol to benefit to other wallets or Dapps. We think it could also be complementary down the road to mobile light clients like Substrate Connect (check **Future Plans** section). - - ![TTV overview overview drawio](https://user-images.githubusercontent.com/4605611/144742049-54d3a212-b471-4a69-9f44-adfb150814ca.png#gh-light-mode-only) - ![TTV overview overview dark drawio](https://user-images.githubusercontent.com/4605611/144738926-e6f0db47-f7ff-4382-ae5d-251420e23a61.png#gh-dark-mode-only) - - >Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? We want to target Dapp providers in the DeFi ecosystem with developer tools to integrate our solution with their Dapps. We think that our value proposition should be attractive to them. @@ -167,14 +130,13 @@ The need for a wallet to be simpler to set-up and use, as well as the need for h Math Wallet and Gluon are close to our solution. -We think that we could bring a better user experience, security and performance, thanks to a highly scalable layer 2 based on SubstraTEE: +We think that we could bring a better user experience, security and performance, thanks to a highly scalable layer 2 based on SubstraTEE: - Math Wallet is based on MPC that requires heavier computation resources. They also envision smartcards with a screen for their users. It's comparable to our level of security, but more expensive, cumbersome to use, less flexible and more complex to deploy than our solution. - + - Gluon QR code based transaction confirmation that requires 2 screens is more cumbersome for the user. Moreover, this scheme is already exposed to banking trojans with overlay capabilities*. Although their TPM based approach could be complementary down the road to TEE, to mitigate potential future flaws on Intel SGX. -> *see: A high level attack description on solutions that use QR code for transaction confirmations [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) - +> *see: A high level attack description on solutions that use QR code for transaction confirmations [Are cryptocurrency wallets more at risk than ever?](https://medium.com/@jlleleu/are-cryptocurrency-wallets-more-at-risk-than-ever-cf1ce9725de7) ## Team :busts_in_silhouette: @@ -189,7 +151,6 @@ We think that we could bring a better user experience, security and performance, - Aude Bourdouxhe - Philippe Salats (advisor) - ### Contact - **Contact Name:** Jean-Luc Leleu @@ -202,6 +163,7 @@ We think that we could bring a better user experience, security and performance, - **Registered Legal Entity:** N/A - we are still in the process of establishing a legal entity. ### Team's experience + [Team deck](https://docs.google.com/presentation/d/1AuM5YO4ysFqoj3uquQ46NJIprDSaALZrqUqAef-ITns/edit?usp=sharing) We are now multiple security and fintech entrepreneurs, security researchers, patents fillers who turned open-source developers and blockchain enthusiasts. @@ -212,23 +174,19 @@ We are now multiple security and fintech entrepreneurs, security researchers, p - https://github.com/nathanprat - ### Team LinkedIn Profiles (if available) - https://www.linkedin.com/in/jlleleu/ Jean-Luc Leleu - https://www.linkedin.com/in/nathan-prat/ Nathan Part - -- https://www.linkedin.com/in/eliotjfl/ Eliot Leleu - -- https://www.linkedin.com/in/jlhoenen/ Jean-Louis Hoenen -- https://www.linkedin.com/in/aude-bourdouxhe-40656b28/ Aude Bourdouxhe - -- https://www.linkedin.com/in/philippesalats/ Philippe Salats (advisor) +- https://www.linkedin.com/in/eliotjfl/ Eliot Leleu +- https://www.linkedin.com/in/jlhoenen/ Jean-Louis Hoenen +- https://www.linkedin.com/in/aude-bourdouxhe-40656b28/ Aude Bourdouxhe +- https://www.linkedin.com/in/philippesalats/ Philippe Salats (advisor) ## Development Roadmap :nut_and_bolt: @@ -253,11 +211,8 @@ We are now multiple security and fintech entrepreneurs, security researchers, p | 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | | 1. | GCF Substrate Interface | GCF external service interface to interact with the following Substrate modules and IPFS. | | 2. | Substrate module: GCF CFG | We will create a Substrate GCF configuration pallet that will store GCF encrypted configuration information on chain (including cid of master circuit file, master key and other security parameter to ensure security of circuit production. | -| 3. | Substrate GCF CFG CLI| A CLI to set-up GCF configuration pallet. | +| 3. | Substrate GCF CFG CLI| A CLI to set-up GCF configuration pallet. | | 4. | Substrate module: OCW GCF | We will create an OCW pallet that will control and interact with GCF external service - Launch GC production and get resulted GC cid on IPFS. | - - - ### Milestone 2 — GC Management in Substrate modules and Transaction Validation protocol use case (first part) @@ -274,7 +229,7 @@ We are now multiple security and fintech entrepreneurs, security researchers, p | 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | | 1. | Substrate module OCW GCP | We will create an OCW GC provider to interact with a GC evaluator/IPFS client. | | 2. | Substrate module: Authenticator| We will create a Substrate Authenticator pallet that will implement the Transaction Validation protocol to manage GC evaluator and IPFS client.| -| 3. | Substrate GCP CLI| A CLI to request GC cid for evaluation. | +| 3. | Substrate GCP CLI| A CLI to request GC cid for evaluation. | ### Milestone 3 — Transaction Validation protocol with mobile use case (second part) @@ -308,30 +263,37 @@ We are now multiple security and fintech entrepreneurs, security researchers, p | 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | | 1. | Substrate modules Authenticator port in TEE | We will migrate Authenticator in SubstraTEE/IntegriTEE workers. | | 2. | Substrate module Mobile Registry port in TEE | We will migrate a part of the Mobile Registry pallet in SubstraTEE/IntegriTEE workers. | - -### Milestone 5 — GCF in TEE +### Milestone 5 — GCF Garbling service part in TEE (amended) -- **Estimated Duration:** 1 month +- **Estimated Duration:** 6 weeks - **FTE:** 2.2 - **Costs:** 9,400 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | MIT | -| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can manage GCF in IntelSGX/Asylo. | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can manage GCF garbling service part in IntelSGX | | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 0e. | Article | We will publish an **article**/workshop that explains what was done/achieved as part of the grant. (Content, language and medium should reflect your target audience described above.) | -| 1. | GCF external service in TEE | We will migrate GCF service in TEE/Intel SGX with Asylo framework. | - +| 0e. | Article | We will write and share (not officially publish as we are still in stealth mode) an **article** that explains what was done/achieved with the grant. (Content, language and medium should reflect your target audience described above.) | +| 1. | replacement of JustGarble (GPL) with Swanky/Fancy-Garbling (MIT)| In order to use a TEE framework we need a non-GPL garbling scheme code | +| 2. | part of GCF external service in TEE | We will migrate the circuit garbling service part in TEE/Intel SGX| +| 3. | android client garbled circuit evaluation updated | we will update the evaluator on android with the Fancy-Garbling scheme| -## Future Plans +> **notes regarding this change:** +>1: We have decided to let the creation of the Master/Configuration logical circuit part managed by ocwCircuit outside of TEE because api_circuit is not critical from a security standpoint in our use case.So, we have no reason to manage it within a TEE. +> +>2-3: We replaced the GPL code of JustGarble by Fancy-Garbling because we can't use GPL licence with a TEE framework. Fancy-Garbling is a classic garbling scheme using a different circuit file format and mainly design for multi-party-computation use cases. So, the change slightly impacts circuit garbling performance. As a consequence we aim at proposing a slight refactoring of the code to ensure performance optimization in a follow-up grant to achieve performance at least comparable to JustGarble. Potentially adding a permutation based garbling scheme like the one used by JustGarble if required. + + +## Future Plans + >How we intend to use, enhance, promote and support your project in the short term: - We aim to create a user community and get in talks with Dapp and especially DeFi players with a tailored value proposition for them @@ -339,7 +301,6 @@ We are now multiple security and fintech entrepreneurs, security researchers, p - Continuous Liquidity Pool (native cross-chain swaps) - Seignorage - Quadratic Voting - - Wallet MVP launch with basic features including Social Recovery and Key management service (potential following grant application submissions) @@ -353,18 +314,15 @@ We are now multiple security and fintech entrepreneurs, security researchers, p - Bounty to crack our transaction validation protocol when both Android protected confirmation and detection of adverse code execution will be deployed - - Continuous Liquidity Pool (like THORChain but with higher security and performance that leverages TEE/MPC/TTS + Trusted Transaction Validation protocol with multisig options (mobiles + yubikey) for validators and large liquidity owners - - - Seignorage mechanism by creating synthetic assets (like UST on the Terra blockchain) - - - Quadratic Voting/Funding features to incentivize the CLP and Seignorage functions and address potential future use cases +- Continuous Liquidity Pool (like THORChain but with higher security and performance that leverages TEE/MPC/TTS + Trusted Transaction Validation protocol with multisig options (mobiles + yubikey) for validators and large liquidity owners ->The team's long-term plans and intentions in relation to it. +- Seignorage mechanism by creating synthetic assets (like UST on the Terra blockchain) +- Quadratic Voting/Funding features to incentivize the CLP and Seignorage functions and address potential future use cases -- Include a TEE layer 2 to manage a Root of trust based on full HSM hardware (with YubiHSM type of solution) to provide a 3 tier distributed HSM capability - +>The team's long-term plans and intentions in relation to it. +- Include a TEE layer 2 to manage a Root of trust based on full HSM hardware (with YubiHSM type of solution) to provide a 3 tier distributed HSM capability - Investigate potential integration with Substrate Connect to increase the security and flexibility of our solution with potential additional on-chain/off-chain data/features at mobile/browser level @@ -372,13 +330,14 @@ We are now multiple security and fintech entrepreneurs, security researchers, p ![3T DHSM overview dark drawio](https://user-images.githubusercontent.com/4605611/144741651-ff9f0bb0-91cb-4b76-8f0e-097395303723.png#gh-dark-mode-only) - - Research on other human brain decryption capabilities (like Visual Cryptography, Audio Cryptography, etc...): the long term goal is to increase our capabilities to differentiate bots with IA capabilities from real humans ([Review of the use of human senses and capabilities in cryptography](https://www.sciencedirect.com/science/article/pii/S1574013720304408)) ## Additional Information :heavy_plus_sign: -> **How did you hear about the Grants Program?** +> **How did you hear about the Grants Program?** + - We are following the Polkadot ecosystem since its early stage + > Others -- We have just started a conversation with a team working in stealth mode on a massive blockchain project that is interested in our solution +- We have just started a conversation with a team working in stealth mode on a massive blockchain project that is interested in our solution diff --git a/applications/Interstellar-network2.md b/applications/Interstellar-network2.md new file mode 100644 index 00000000000..4e9704fef6d --- /dev/null +++ b/applications/Interstellar-network2.md @@ -0,0 +1,208 @@ +# Interstellar - Wallet Phase 2 (amended) + + +- **Team Name:** Interstellar +- **Payment Address:** Fiat 04.04.2023, 22:42 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + + +## Project Overview :page_facing_up: + +**Follow-up of Interstellar- Wallet Phase 1**: Link to the application pull request: [w3f/Grants-Program#734](https://github.com/w3f/Grants-Program/pull/734). Amendment: [w3f/Grants-Program#1354](https://github.com/w3f/Grants-Program/pull/1354) + +### Overview + +**The FTX collapse highlights the importance of self-custody for the Web3 ecosystem**. + +Currently, there are only two categories of self-custodial wallets available: Hot Wallets and Cold Wallets. Both options come with significant trade-offs and are not well-suited for providing blockchain access to the general public. + +To address the most crucial issues faced by current wallet options - User Experience and Security - a new type of wallet is required. + +Typically, when we think about accessing the blockchain through a cold wallet, we expect a complicated user experience. +Interstellar aims to change this perception through a new approach and technology. + +We strongly believe that securely linking and registering access device security components with a blockchain-based autonomous system is an extremely powerful concept. It can provide a future-proof solution for addressing the current security, usability, and privacy issues associated with current **centralized** non-custodial wallet software. + +In terms of security, this approach utilizes the current and future mobile device security capabilities by implementing a secure distributed protocol. It addresses the current lack of third-party protection and management while also adding the necessary decentralized backend services to enhance security against evolving cyber threats. + +Regarding usability, this approach simplifies the user experience by adding transparent services like Instant Onboarding. + +Privacy can also be addressed using methods such as stealth addresses and other private schemes. + +Additionally, implementing this approach increases the overall system's auditability, potentially enabling the management of a guarantee fund to aid users in case of issues. + +Furthermore, this approach can enable new types of recovery schemes that would be impossible without a secure decentralized autonomous system backend. + + +A **highly secure and convenient wallet system** is necessary to combat cyber threats and ensures larger adoption. + +Our solution transforms mobile devices into cold wallets, with private keys protected at the hardware level: + +- Secure Element on mobile for proxy private keys associated with transaction requests and confirmations. +- Trusted Execution Environment (TEE) on nodes for private keys associated with assets. + +This hardware security, combined with a Trusted Transaction Validation Protocol, offers robust protection against state-of-the-art malware, including banking Trojans, and prepares for future targeted attacks. + +Interstellar is more than a wallet, we have designed **a novel secure access layer for web3** managed with a blockchain that register mobile hardware/secure elements/TEEs to protect transaction with a strong multifactor authentication (based on hardware and software computation privacy scheme i.e. garbled circuit). + +Using a blockchain for the management of multi-chain transactions offers extra security and auditability features and dramatically increase convenience for the user: + +- **Instant Access to Web3 services**, without any wallet set-up. +- **Trusted beneficiaries/contacts**, with destination public keys stored only on the blockchain nodes. +- **Adaptive Security**, allowing users to personalize the security level based on theirs need i.e. transaction amount to trigger validation, chose number of recovery options, etc. +- **Transaction auditability**, extra auditability security layer. +- **Social Recovery** ideally based on Polkadot pallet. + +In the medium/long term (see future plan for more details): + +- **A novel hardware-based recovery (through NFC/BLE) to further enhance security and convenience**, i.e. just a tap on your mobile with your NFC device to trigger the recovery process. + +- **ML real-time Malware detection model** based on proof of legitimate software execution protection that increases the model accuracy (potential research project to address targeted attacks) +- **User inputs verification** based on behavioral biometric model (proven with 99% accuracy) that can be correlated with ML detection model. + + +This approach achieves a **highly secure level for newcomers to easily onboard web3**, and serves as an **alternative to hardware wallets for crypto veterans**. + +Our technology has the potential to disrupt the hardware wallet, smart contract wallet, and even hot wallet markets. + + +### Project Details + + +A short video on the Interstellar solution (click on the following image) + +[](https://clipchamp.com/watch/nwzybRger1x "Interstellar Video: 55") +- Designs of UI components +https://book.interstellar.gg/Mobile_App.html + +- Documentation of core components +https://book.interstellar.gg/ + +#### Architecture Overview +![Architecture overview](https://book.interstellar.gg/fig/Architecture-mobile-L1-L2-Signers.svg "architecture L1 L2 signer") +#### TTVP Detailed +![TTVP Detailed](https://book.interstellar.gg/fig/Transaction_Validation_Module.svg "TTVP detailed") + + +#### Technology stack + +- VHDL +- C/C++ +- Java/Kotlin/Jetpack Compose/Swift/Swift UI +- gRPC +- Rust/Substrate +- IPFS + + +### Ecosystem Fit + +At parisDOT.comm we had a fantastic opportunity to present our project to the leading teams in the Polkadot Parachain community. And the feedback we received was nothing short of extraordinary. Our solution, which aims to provide both hardware security and user-friendliness in a wallet solution, struck a chord with the teams. + +Their positive response is a testament to the importance of a solution that addresses this critical need in the Polkadot ecosystem and beyond. The teams were not only impressed with our solution, but they were also eager to put it to the test as soon as it becomes available. + +This is a major market fit milestone for us, and we're thrilled to have the support of such influential players in the Polkadot community. We're dedicated to delivering a solution that meets their expectations and contributes to the continued growth and success of the Polkadot ecosystem. + +We are in active conversations with some of the teams we met there, and continuously have new discussions with new teams also beyond the Polkadot ecosystem. So far, everyone is impressed and enthusiastic about the solution. + + +## Team :busts_in_silhouette: + + +### Team members +- Name of team leader: +- Jean-Luc Leleu +- Names of team members: +- Nathan Prat +- Eliot Leleu + +- Philippe Salats (advisor) + +### Contact + +- **Contact Name:** Jean-Luc Leleu +- **Contact Email:** jll@interstellar.gg +- **Website:** https://www.interstellar.gg/ + + +### Legal Structure + +- **Registered Address:** 61 rue de Lyon, Paris, France +- **Registered Legal Entity:** Interstellar SAS + +### Team's experience +We are now multiple security and fintech entrepreneurs, security researchers, patents fillers who turned open-source developers and blockchain enthusiasts. + + +### Team Code Repos + +- https://github.com/Interstellar-Network + +- https://github.com/nathanprat + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/jlleleu/ Jean-Luc Leleu + +- https://www.linkedin.com/in/nathan-prat/ Nathan Part + +- https://www.linkedin.com/in/eliotjfl/ Eliot Leleu + + +- https://www.linkedin.com/in/philippesalats/ Philippe Salats (advisor) + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 2.5 +- **Total Costs:** 30,000 USD + +### Milestone 1 — New Garbling scheme + +- **Estimated duration:** 4 weeks +- **FTE:** 2.5 +- **Costs:** 15,000 USD + + +| Number | Deliverable | Specification | +| ------: | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **0a.** | License | APACHE 2 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up our stack and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.| | | | +| 1. | Garble Circuit pallet update | We will rewrite the garbled circuit evaluation scheme to target at least **60 fps** through parralelization, caching and likely with an efficient [1.permutation-based garbling scheme: see 4.5](https://www.cs.fsu.edu/~tvhoang/thesis.pdf) optimized for performance or a [2.new garbling scheme](https://www.esat.kuleuven.be/cosic/publications/article-3351.pdf) that could potentially require lower computation cost per gate| + + + + +### Milestone 2 — Circuit design optimization and light security screen + +- **Estimated duration:** 4 weeks +- **FTE:** 2.5 +- **Costs:** 15,000 USD + + +| Number | Deliverable | Specification | +| ------: | ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **0a.** | License | APACHE 2 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up our stack and send test transactions, which will show how the new functionality works. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | + | | | | +| 1. | Display Circuit update | We will modify the current display circuit to enable a more comfortable user experience by decreasing the cognitive load needed for the user to read the screen. - likely by adding specific sub-circuits to manage a set of probabilities of displaying segments for each frame, then fine tuned segments ON/OFF per frame to improve readbility +| 2. | Light security screen | We will provide a less secure but very comfortable to read secure screen version using fading with less blinking (link) - this non-screenshot proof version will be used later with our adaptive security framework | + +**Additional information (reason for amendment):** + +As we prioritize the user experience and aim to showcase the FPS improvement and overall viusal improvement for the user compared to the previous milestone, there is no need for a Docker here. Instead, we provide an offline demo app to simplify the evaluation. + +However, if you'd like to test the full pipeline for this milestone, we can provide you with both a Docker and an online version of the app and the related demo tutorial. + + + + + + + + + diff --git a/applications/InvArch.md b/applications/InvArch.md index 96f5dc5371a..0d178fa765d 100644 --- a/applications/InvArch.md +++ b/applications/InvArch.md @@ -1,22 +1,23 @@ -# W3F Grant Proposal +# The InvArch - INV4 Frame : IP Assets, Licensings, & CLI tool for the Substate ecosystem. -* **Project Name:** The InvArch - INV4 Frame : IP Assets, Licensings, & CLI tool for the Substate ecosystem. -* **Team Name:** InvArch Network -* **aUSD Payment Address:** 25aeg1bNLXaYm526R7cXfQNtpEvnv9S23eR17AeDtm5BD7Ce (PLEASE NOTE CHANGE) -* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Team Name:** InvArch Network +- **BTC Payment Address:** bc1qr2wg0snstgn4d2wc0alhhyxs32j58hhdrh5zal (PLEASE NOTE CHANGE) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 ## Project Overview :page_facing_up: ### Overview -* The InvArch Network is the cross-chain IP development & authentication hub built on Polkadot. InvArch provides a proven & validated "best-to-market" -environment for IP Assets & dApps, where as the InvArch Tinkernet provides a "first-to-market" bleeding-edge environment on Kusama for testing. +- The InvArch Network is the cross-chain IP development & authentication hub built on Polkadot. InvArch provides a proven & validated "best-to-market" +environment for IP Assets & dApps, where as the InvArch Tinkernet provides a "first-to-market" bleeding-edge environment on Kusama for testing. The Eureka Relay is envisioned for future scaling improvements. -### The InvArch Network is powered by the INV4, On-Chain Innovation Funding (OCIF), & Cross-Chain Authentication (XCA) protocols. -* INV4 is responsible for defining how IP Assets are defined, stored, & interacted with across Web3. -* OCIF harnesses new & transparent funding possibilities to direct wealth towards the incentivization of realizing IP & unlocking true value. -* XCA unlocks the power of a trustless XC file tracking & data fingerprinting solution that realizes files just as uniquely as NFTs do with CIDs. +### The InvArch Network is powered by the INV4, On-Chain Innovation Funding (OCIF), & Cross-Chain Authentication (XCA) protocols + +- INV4 is responsible for defining how IP Assets are defined, stored, & interacted with across Web3. + +- OCIF harnesses new & transparent funding possibilities to direct wealth towards the incentivization of realizing IP & unlocking true value. +- XCA unlocks the power of a trustless XC file tracking & data fingerprinting solution that realizes files just as uniquely as NFTs do with CIDs. Under this grant, the [InvArch INV4 FRAME](https://github.com/InvArch/InvArch-Frames/tree/main/INV4) will be released & maintained by the InvArch Network team. The INV4 FRAME is a Rust Pallet Module for Substrate-based chains that realizes the INV4 protocol, and as a result, the possibility for @@ -30,29 +31,32 @@ mission. We have also held many exciting discussions with other Parachain teams ### Project Details -* [InvArch Website](https://invarch.network/) -* [InvArch EduSeries 1 (Background)](https://invarch.medium.com/invarch-eduseries-1-the-i-p-war-zone-innovation-graveyard-we-live-in-1f11ded41b5f) -* [InvArch EduSeries 2 (IPS & IPF)](https://invarch.medium.com/invarch-eduseries-2-blockchains-bright-light-a-shining-future-for-ip-rights-164b7a4eaba5) -* [InvArch EduSeries 3 (IP License)](https://invarch.medium.com/invarch-eduseries-3-web3s-super-highway-the-future-of-transporting-ip-rights-ce1368800927) -* [InvArch EduSeries 4 (IPT & SIPA)](https://invarch.medium.com/invarch-eduseries-4-the-sipa-revolution-a-new-golden-age-for-innovation-3e90aed4a57) +- [InvArch Website](https://invarch.network/) +- [InvArch EduSeries 1 (Background)](https://invarch.medium.com/invarch-eduseries-1-the-i-p-war-zone-innovation-graveyard-we-live-in-1f11ded41b5f) +- [InvArch EduSeries 2 (IPS & IPF)](https://invarch.medium.com/invarch-eduseries-2-blockchains-bright-light-a-shining-future-for-ip-rights-164b7a4eaba5) +- [InvArch EduSeries 3 (IP License)](https://invarch.medium.com/invarch-eduseries-3-web3s-super-highway-the-future-of-transporting-ip-rights-ce1368800927) +- [InvArch EduSeries 4 (IPT & SIPA)](https://invarch.medium.com/invarch-eduseries-4-the-sipa-revolution-a-new-golden-age-for-innovation-3e90aed4a57) -
          - +
          +
          -### InvArch approaches ideas (IP) as a set of non-fungible components: The INV4 Protocol -* IP Sets - Either a Root or Parent IP Set, and/or a Child Subset (collections) of interchangeable & freely composable IP Files & NFTs. -* IP Files - NFT-based files that which can emulate or contain any content or data as found as any other file on the internet & local devices. -* IP Licenses - On-chain Licensing agreements pegged to an IP Set that can be used to allocate ownership, manage custom access, & define utility. -* IP Tokens - Fungible tokens pegged to an IP Set & managed using an IP License; multiple unique classes of IP Tokens can be pegged to the same IP Set. +### InvArch approaches ideas (IP) as a set of non-fungible components: The INV4 Protocol + +- IP Sets - Either a Root or Parent IP Set, and/or a Child Subset (collections) of interchangeable & freely composable IP Files & NFTs. -* When interacting with `Pallet_ips` users can call the following functions `create_ips`, `destroy`, `append`, `remove`, `Allow_replica`, `Disallow_replica`, & `Create_replica`. -* When interacting with `Pallet_ipf` users can call the following functions: `mint` & `burn`. -* When interacting with `Pallet_ipl` users can call the following functions: `set_asset_weight` & `set_permission`. -* When interacting with `Pallet_ipt` users can call the following functions: `mint`, `burn`, `create_subasset`, `operate_multisig`, `vote_multisig`, `withdraw_vote_multisig`, `burn`. -* While some hidden functions are only callable by the actual Pallets in the INV4 FRAME themselves. +- IP Files - NFT-based files that which can emulate or contain any content or data as found as any other file on the internet & local devices. +- IP Licenses - On-chain Licensing agreements pegged to an IP Set that can be used to allocate ownership, manage custom access, & define utility. +- IP Tokens - Fungible tokens pegged to an IP Set & managed using an IP License; multiple unique classes of IP Tokens can be pegged to the same IP Set. + +- When interacting with `Pallet_ips` users can call the following functions `create_ips`, `destroy`, `append`, `remove`, `Allow_replica`, `Disallow_replica`, & `Create_replica`. +- When interacting with `Pallet_ipf` users can call the following functions: `mint` & `burn`. +- When interacting with `Pallet_ipl` users can call the following functions: `set_asset_weight` & `set_permission`. +- When interacting with `Pallet_ipt` users can call the following functions: `mint`, `burn`, `create_subasset`, `operate_multisig`, `vote_multisig`, `withdraw_vote_multisig`, `burn`. +- While some hidden functions are only callable by the actual Pallets in the INV4 FRAME themselves. ### Technologies + 1. Rust 2. Substrate 3. Polkadot.js @@ -62,135 +66,148 @@ mission. We have also held many exciting discussions with other Parachain teams ### InvArch INV4 FRAME ### 1. IP Sets & IP Files -* `Pallet_ips` - Provides basic functionality for creating and managing an `IPSet`. You can think of an `IPSet` as an idea, which is basically a collection of components (intellectual property tokens) that define and describe that idea. -* `Pallet_ipf` - Provides basic functionality for creating and managing an `IPToken`. You can think of an `IPToken` as a component of an idea. For example, a business summary PDF file, or even a 3D rendering of a prototype mold. When combined and stored in an `IPSet`, that collection forms the foundtion for an idea. The more detailed and/or comprehensive an `IPSet` is, the stronger the idea. -
          - +- `Pallet_ips` - Provides basic functionality for creating and managing an `IPSet`. You can think of an `IPSet` as an idea, which is basically a collection of components (intellectual property tokens) that define and describe that idea. + +- `Pallet_ipf` - Provides basic functionality for creating and managing an `IPToken`. You can think of an `IPToken` as a component of an idea. For example, a business summary PDF file, or even a 3D rendering of a prototype mold. When combined and stored in an `IPSet`, that collection forms the foundtion for an idea. The more detailed and/or comprehensive an `IPSet` is, the stronger the idea. + +
          +
          ### 2. IP Licenses & Tokens -* `Pallet_dev` - Provides basic functionality for structuring, managing, and listing a `DEV`(Decentralized Entrepreneurial Venture). You can think of a `DEV` as an agreement between multiple parties to come together as cofounders over a project in order to contribute towards an `IPSet`'s actualization. -* `Pallet_dao` - Provides basic functionality for creating and managing a `DAO` that helps govern a `DEV`. You can think of a `DAO` as a `DEV`'s governance mechanism. It helps regulate the and ensure the integrity and prudence of participants within a `DEV`. -* `Pallet_worklog` - Provides basic functionality for creating and managing a `WorkLog` within a `DEV`. You can think of a `Worklog` as a `DEV`'s method of recording and storing milestone/deliverables progressions and completions. -
          - +- `Pallet_dev` - Provides basic functionality for structuring, managing, and listing a `DEV`(Decentralized Entrepreneurial Venture). You can think of a `DEV` as an agreement between multiple parties to come together as cofounders over a project in order to contribute towards an `IPSet`'s actualization. + +- `Pallet_dao` - Provides basic functionality for creating and managing a `DAO` that helps govern a `DEV`. You can think of a `DAO` as a `DEV`'s governance mechanism. It helps regulate the and ensure the integrity and prudence of participants within a `DEV`. +- `Pallet_worklog` - Provides basic functionality for creating and managing a `WorkLog` within a `DEV`. You can think of a `Worklog` as a `DEV`'s method of recording and storing milestone/deliverables progressions and completions. + +
          +
          -* Ownership can be fractionalized using multiple pegged fungible assets representing ownership (ARO). An ARO is (typically) reflected in the first IP Token (IPT) attached to an IP Set. The asset ID of an ARO is defined in a copyright ownership agreement, and there can be multiples of these fungible assets. +- Ownership can be fractionalized using multiple pegged fungible assets representing ownership (ARO). An ARO is (typically) reflected in the first IP Token (IPT) attached to an IP Set. The asset ID of an ARO is defined in a copyright ownership agreement, and there can be multiples of these fungible assets. ### Ecosystem Fit -:link: **Chains and Pallets**
          +:link: **Chains and Pallets**
          InvArch applies the categories below: -* NFT -* Governance/DAO -* Other (IP Assets) + +- NFT +- Governance/DAO +- Other (IP Assets) ### Project Uniqueness -* The world's first truly composable network for fully unlocking IP assets & on-chain IP attribution solution (that is flexible for its assets to experience international compliance in business, copyright, & legal transactions. InvArch revolutionizes the world of innovation beginning at the very start of development & pushes the bounds of web3 by taking existing concepts & challenging them to be different and better. By unlocking new doors & redefining what’s possible, InvArch will revolutionize the worlds of technical development & real-world collaboration down to their very core. + +- The world's first truly composable network for fully unlocking IP assets & on-chain IP attribution solution (that is flexible for its assets to experience international compliance in business, copyright, & legal transactions. InvArch revolutionizes the world of innovation beginning at the very start of development & pushes the bounds of web3 by taking existing concepts & challenging them to be different and better. By unlocking new doors & redefining what’s possible, InvArch will revolutionize the worlds of technical development & real-world collaboration down to their very core. ### Target Audience -* Entrepreneurs/Innovators -* Developers/DAOs/Artists -* Educators/Researchers -* Philanthropists + +- Entrepreneurs/Innovators + +- Developers/DAOs/Artists +- Educators/Researchers +- Philanthropists ### Problem Addressed -* On-chain IP attribution (Achieved with this grant proposal). -* International flexibility for compliance (Achieved with this grant proposal). -* Barriers of access to startup capital. (OCIF Protocol) -* On-chain donations for access & transparency. (OCIF Protocol) -* File piracy & inability to securely expose data. (XCA Protocol) + +- On-chain IP attribution (Achieved with this grant proposal). + +- International flexibility for compliance (Achieved with this grant proposal). +- Barriers of access to startup capital. (OCIF Protocol) +- On-chain donations for access & transparency. (OCIF Protocol) +- File piracy & inability to securely expose data. (XCA Protocol) ## Team :busts_in_silhouette: -### Team members +### Team members + (Development & Engineers) -* [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development -* [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development -* [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development -* [Mindaugas Savickas](https://www.linkedin.com/in/savickas) - Co-Founder & Head of Ecosystem Development -* [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer +- [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development +- [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development +- [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development +- [Mindaugas Savickas](https://www.linkedin.com/in/savickas) - Co-Founder & Head of Ecosystem Development +- [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer -* [Brunk Škvorc](https://www.linkedin.com/in/swader) - Technical Advisor (Founder, RMRK) -* [Marvin Tong](https://twitter.com/marvin_tong) - Product Advisor (Founder, Phala Network) +- [Brunk Škvorc](https://www.linkedin.com/in/swader) - Technical Advisor (Founder, RMRK) +- [Marvin Tong](https://twitter.com/marvin_tong) - Product Advisor (Founder, Phala Network) ### Contact -* **Contact Name:** Dakota Barnett -* **Contact Email:** dakota@invarch.network -* **Website:** [https://invarch.network](https://www.invarch.network) +- **Contact Name:** Dakota Barnett +- **Contact Email:** dakota@invarch.network +- **Website:** [https://invarch.network](https://www.invarch.network) ### Legal Structure -The InvArch Association.
          -Baarerstrasse 86,
          -6300 Zug, Switzerland
          +The InvArch Association. + +Baarerstrasse 86, + +6300 Zug, Switzerland ### Founders' experiences -* [Dakota Barnett](https://www.linkedin.com/in/dakotasb97) has experience succesfully directing and leading multi-national teams, overseeing and directing -succesful project management strategies, and scaling large operations. He's a seasoned developer, programming in JavaScript (3yrs), Node.js (2yrs), +- [Dakota Barnett](https://www.linkedin.com/in/dakotasb97) has experience succesfully directing and leading multi-national teams, overseeing and directing +successful project management strategies, and scaling large operations. He's a seasoned developer, programming in JavaScript (3yrs), Node.js (2yrs), React.js (2yrs), Python (2yrs), Rust (1yr), and the Substrate framework (1yr). Past work includes private projects for previous employers focused on machine learning, task automation, and website development. 💡 -* [Gabriel Facco de Arruda](https://github.com/arrudagates) has experience as a Rust Developer, programming for the past 3 years, and as a developer in +- [Gabriel Facco de Arruda](https://github.com/arrudagates) has experience as a Rust Developer, programming for the past 3 years, and as a developer in the Web3 ecosystem. Gabriel is a a dedicated programmer and DeFi ninja who loves cutting edge technology and all things Substrate/Rust. He is committed to building applications that help promote a more decentralized global economy, and comes with past experience developing and scaling such applications. He brings direct experience developing applications for the Substrate ecosystem and as a Polkadot ecosystem contributor dedicated to building the future. 🧠 -* [Kresna Sucandra](https://github.com/SHA888) is a dedicated programmer and Parity/Substrate enthusiast. Kusandra has been dedicated for the past year +- [Kresna Sucandra](https://github.com/SHA888) is a dedicated programmer and Parity/Substrate enthusiast. Kusandra has been dedicated for the past year learning everything there is to know about the Web3 ecosystem. Kresna is a medical doctor turned programmer with a background in Substrate blockchain development focusing on multi-chain interoperability, DeFi, NFTs, and the Metaverse. He brings first-hand insights and experience as a former blockchain -startup co-founder and developer with a history focusing on JavaScript and Rust programming. Kresna is a Polkadot ecosystem contributor who loves +startup co-founder and developer with a history focusing on JavaScript and Rust programming. Kresna is a Polkadot ecosystem contributor who loves entrepreneurship. 🚀 -* [Mindaugas Savickas](https://www.linkedin.com/in/savickas) is a veteran marketing advisor and fundraising rockstar with a background providing strategic marketing solutions and scaling over 40+ product & marketing teams worldwide. He Provides a proven history of success and strategic insights as a tech marketing guru who lives & breathes outside of the box. 📈 +- [Mindaugas Savickas](https://www.linkedin.com/in/savickas) is a veteran marketing advisor and fundraising rockstar with a background providing strategic marketing solutions and scaling over 40+ product & marketing teams worldwide. He Provides a proven history of success and strategic insights as a tech marketing guru who lives & breathes outside of the box. 📈 ### Team Code Repos -* InvArch Github: https://github.com/InvArch -* InvArch Node https://github.com/InvArch/InvArch-node -* InvArch Frames : https://github.com/InvArch/InvArch-Frames -* InvArch INV4 FRAME : https://github.com/InvArch/InvArch-Frames/tree/main/INV4 +- InvArch Github: https://github.com/InvArch +- InvArch Node https://github.com/InvArch/InvArch-node +- InvArch Frames : https://github.com/InvArch/InvArch-Frames +- InvArch INV4 FRAME : https://github.com/InvArch/InvArch-Frames/tree/main/INV4 Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. -* [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development -* [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development -* [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development -* [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer +- [Dakota Barnett](https://www.linkedin.com/in/xcastronaut) - Founder & Head of Development +- [Gabriel Facco de Arruda](https://github.com/arrudagates) - Co-Founder & Head of Technology Development +- [Kresna Sucandra](https://github.com/SHA888) - Co-Founder & Head of Protocol Development +- [Matheus Braña Iannuzzi Baliones](https://github.com/S0raWasTaken) - Rust Core Engineer ### Team LinkedIn Profiles (if available) -* [Dakota Barnett](https://www.linkedin.com/in/dakotasb97), Founder -* [Gabriel Facco de Arruda](https://www.linkedin.com/in/gabriel-facco-de-arruda-00880787), Sr. Rust Dev -* [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra/), Substrate Dev -* [Mindaugas Savickas](https://www.linkedin.com/in/savickas), Head of Marketing +- [Dakota Barnett](https://www.linkedin.com/in/dakotasb97), Founder +- [Gabriel Facco de Arruda](https://www.linkedin.com/in/gabriel-facco-de-arruda-00880787), Sr. Rust Dev +- [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra/), Substrate Dev +- [Mindaugas Savickas](https://www.linkedin.com/in/savickas), Head of Marketing ## Development Status :open_book: -* InvArch is a project in the Substrate Builders Program. -* The INV4 protocol is complete & available for public testing. -* Gearing up for the launch of the Brainstorm Testnet (Solo-chain) on May 23rd, 2022. -* Preparing the InvArch Tinkernet for a crowdloan campaign & slot auction on the Kusama relay. +- InvArch is a project in the Substrate Builders Program. +- The INV4 protocol is complete & available for public testing. +- Gearing up for the launch of the Brainstorm Testnet (Solo-chain) on May 23rd, 2022. +- Preparing the InvArch Tinkernet for a crowdloan campaign & slot auction on the Kusama relay. -* INV4 v2 & xcINV4 (Est. August, 2022) will add additional functionality, wrapping of other Substrate NFTs, & authentication of assets. +- INV4 v2 & xcINV4 (Est. August, 2022) will add additional functionality, wrapping of other Substrate NFTs, & authentication of assets. ## Development Roadmap :nut_and_bolt: ### Overview -* **Full-Time Equivalent (FTE):** 2.5 -* **Total Costs:** $25,000 equivalent +- **Full-Time Equivalent (FTE):** 2.5 +- **Total Costs:** $25,000 equivalent ### Milestone 1 — Implement IP Pallets & Standards -* **Estimated duration:** 4 weeks -* **FTE:** 2 -* **Costs:** $10,000 equivalent +- **Estimated duration:** 4 weeks +- **FTE:** 2 +- **Costs:** $10,000 equivalent Goal - Develop Substrate Pallets that fully realize Git-level composability for NFTs; fully emulating file & folder functionalities. @@ -203,32 +220,32 @@ Goal - Develop Substrate Pallets that fully realize Git-level composability for | 1. | Node Repo | Complete the deployment of the InvArch chain (https://github.com/InvArch/InvArch) | | 2a. | Pallet_ips | Complete the development of [pallet_ips](https://github.com/InvArch/InvArch-Pallet-Library/tree/main/ips) and realize the IP Sets standard. | | 2b. | Pallet_ipf | Complete the development of [pallet_ipf](https://github.com/InvArch/InvArch-Pallet-Library/tree/main/ipt) and realize the IP Token Standard. | -| 3. | Article | We will write an **article** that explains the work done as part of the grant. | +| 3. | Article | We will write an **article** that explains the work done as part of the grant. | ### Milestone 2 — Implement DEV Pallets & Standards -* **Estimated duration:** 12 weeks -* **FTE:** 3 -* **Costs:** $15,000 equivalent +- **Estimated duration:** 12 weeks +- **FTE:** 3 +- **Costs:** $15,000 equivalent Goal - Develop and deliver the DEV Pallets & Standards for the InvArch Chain/InvArch Pallet Library | Number | Deliverable | Specification | | -----: | ----------- | ------------- | -| 0a. | License | GPLv3 | +| 0a. | License | GPLv3 | | 0b. | Documentation | An introduction video, and appropriate `README.md` files will be included. | | 0c. | Testing Guide | The code will have proper unit-test coverage to ensure functionality and robustness. In the guide we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | | 1a. | Pallet_ipl | complete the development of [pallet_ipl](https://github.com/InvArch/InvArch-Frames/tree/main/INV4/pallet-ipl) and copyright & license structuring mechanism. | | 1b. | Pallet_ipt | Complete the development of [pallet_ipt](https://github.com/InvArch/InvArch-Frames/tree/main/INV4/pallet-ipt) and realize the refungible & multi-layer governance mechanisms. | | 2. | INV4-Git middleware | We will release a middleware tool for managing INV4 assets using the standard git CLI commands transparently. | -| 3. | Article & Video | We will write an **article** that explains the work done as part of the grant, as well as release a video walk through demonstrating the INV4 protocol | +| 3. | Article & Video | We will write an **article** that explains the work done as part of the grant, as well as release a video walk through demonstrating the INV4 protocol | ## Future Plans -* Launch the InvArchitects Assemble Program, the builders program of the InvArch Network. -* Finish Development on the On-Chain Innovation Funding (OCIF) & Cross-Chain Authentication (XCA) protocols. -* Maintain the Brainstorm Testnet, launch the Tinkernet Parachain on Kusama, & deploy the InvArch Network on Polkadot. +- Launch the InvArchitects Assemble Program, the builders program of the InvArch Network. +- Finish Development on the On-Chain Innovation Funding (OCIF) & Cross-Chain Authentication (XCA) protocols. +- Maintain the Brainstorm Testnet, launch the Tinkernet Parachain on Kusama, & deploy the InvArch Network on Polkadot. 1. GitArch - Decentralized, Incentivized, Open-Source On-Chain Repository Platform powered using INV4-Git. 2. Tinkerspace - A VR Sandbox for experimenting, collaborating, & simulating development using INV4 Assets. @@ -236,5 +253,5 @@ Goal - Develop and deliver the DEV Pallets & Standards for the InvArch Chain/Inv ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/JsonRpsee-socks5-proxy.md b/applications/JsonRpsee-socks5-proxy.md new file mode 100644 index 00000000000..4c99316322e --- /dev/null +++ b/applications/JsonRpsee-socks5-proxy.md @@ -0,0 +1,99 @@ +# JsonRpsee socks5 proxy + +* **Team Name:** [gmajor](https://github.com/gmajor-encrypt) +* **Payment Address:** 0xC3094f0ddce699a1Ad9Ef2621DF68Cd297a4c44F(USDC) +* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/2068#issuecomment-1840145149) + +## Project Overview :page_facing_up: + +RFPs [https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/jsonrpsee-proxy-support.md](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/jsonrpsee-proxy-support.md) + +### Overview + +This proposal is to develop a JsonRpsee socks5 middleware proxy. + +### Project Details + +This proposal is to develop a JsonRpsee [socks5](https://datatracker.ietf.org/doc/html/rfc1928) middleware proxy. + + +### Ecosystem Fit + +- Where and how does your project fit into the ecosystem? + + This project is a middleware that can be used to proxy connections using a socks5 proxy. It can be used in any application that uses jsonrpsee as a client. + +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, + yourself)? + + jsonrpsee client developers + +- What need(s) does your project meet? + + Enhance the JsonRpsee package and add support for socks5 proxy + +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? + + Nothing + +## Team :busts_in_silhouette: + +### Team members + +* gmajor + +### Contact + +* **Contact Name:** gmajor +* **Contact Email:** gmajorencrypt@gmail.com +* **Website:** https://github.com/gmajor-encrypt + +### Legal Structure + +individual + +### Team's experience + +I have many years of PHP development experience and nearly five years of blockchain development experience, familiar +with PHP, GOLANG, PYTHON, Nodejs, Rust + +### Team Code Repos + +- https://github.com/gmajor-encrypt/php-scale-codec +- https://github.com/gmajor-encrypt/php-substrate-api +- https://github.com/gmajor-encrypt/scale-codec-comparator +- https://github.com/gmajor-encrypt/sr25519-bindings +- https://github.com/gmajor-encrypt/xcm-tools + +## Development Status :open_book: + +Not yet + +## Development Roadmap :nut_and_bolt: + +### Overview + +* **Total Estimated Duration:** 1 months +* **Total Costs:** 9000 USDC + +### Milestone 1 + + +* **Estimated duration:** 4 week +* **FTE:** 1 +* **Costs:** 9000 USDC + +| Number | Deliverable | Specification | +|-------:|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0a. | License | MIT or Apache 2.0 | +| 0b. | Documentation | Simple documentation on how to use and how to test | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 1. | Socks5 middleware support | Enable a jsonrpsee client to proxy connections using a socks5 proxy | +| 2. | Example | I will now provide an example to demonstrate the usage of this socks 5 middleware. | +| 3. | Pull request | Create pull request merge into [jsonrpsee](https://github.com/paritytech/jsonrpsee) | + + +## Future Plans + +If there are any problems with this feature, I will still maintain it. diff --git a/applications/JuniDB.md b/applications/JuniDB.md index a1372a9d416..817b57aae17 100644 --- a/applications/JuniDB.md +++ b/applications/JuniDB.md @@ -1,12 +1,15 @@ -* **Project Name:** JuniDB +# JuniDB + * **Team Name:** Uddug * **Payment Address:** 0xc45eAd98E95D1962133d9c15847e2EA4E16dfD0b +* **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/254#issuecomment-1404647441) ## Project Overview :page_facing_up: ### Overview It's a very highload action to store large amounts of data on-chain. The most-common and useful solution for decentralised apps is to use IPFS as a data storage and store on-chain only hashes. Our team inspired by the OrbitDB will focus on the scalability, decentralised, easy-learning solution for substrat developers that want to manipulate big amounts of data easily. + #### Key advantages * **Usability** - just integrate and code @@ -22,30 +25,32 @@ It's a very highload action to store large amounts of data on-chain. The most-co Working a lot with blockchain technologies, our team found that it’s data-driven, and thus there are rapidly growing interests in integrating them for more secure and efficient data storage and sharing.We are convinced that blockchain technologies change the world, and have been working hard to create more transparent solutions. We designed and built core infrastructure for decentralised projects. -We have been observing and learning Substrate technologies and find Polkadot as the best ecosystem for us to join depending on technology and strong market position. We believe that our protocol will be useful for other projects in the Polkadot ecosystem. +We have been observing and learning Substrate technologies and find Polkadot as the best ecosystem for us to join depending on technology and strong market position. We believe that our protocol will be useful for other projects in the Polkadot ecosystem. ### Project Details + Substrate pallet provides a configurable database module allows to store and manipulate a big amount of data. Pallet works as an offchain worker and connect data between blockchain and ipfs via offchain::worker. #### Encryption module + Built-in encryption module allows to create a secure database and encrypt all data before its uploading to the database with user account keys. With enabled encryption only account users have access to the database. Data could be decrypted via Web-application after receiving. Module is based on asymmetrical cryptography and uses an account public key to encrypt data on the blockchain side and a private key to decrypt data on the client side. -We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https://github.com/phayes/ecies-ed25519) crate to implement encryptions on backend side. +We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https://github.com/phayes/ecies-ed25519) crate to implement encryptions on backend side. ![scheme A](https://i.postimg.cc/gJds3kj9/encryption.png) -- receive data by RPC request -- Encrypt data by account public key -- Insert encrypted data into ipfs via offfchain::ipfs -- Insert received ipfs hash into storage +* receive data by RPC request +* Encrypt data by account public key +* Insert encrypted data into ipfs via offfchain::ipfs +* Insert received ipfs hash into storage ![scheme B](https://i.postimg.cc/Y9h66G7s/decryption.png) -- catch request to get data by RPC request -- get ipfs hash from storage -- fetch encrypted data from ipfs via offchain::ipfs -- receive encrypted data in RPC response -- decrypt data using user account private key via app ddecryption module +* catch request to get data by RPC request +* get ipfs hash from storage +* fetch encrypted data from ipfs via offchain::ipfs +* receive encrypted data in RPC response +* decrypt data using user account private key via app ddecryption module #### Technical stack @@ -62,6 +67,7 @@ We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https:/ * **ecies-ed25519** - encryption crate #### Public Methods + * **KeyValueInit(name)** - initialise new keyValue database * **KeyValueSet(key, value)** - set given value in keyValue database * **KeyValueGet(key)** - get value for given key @@ -76,74 +82,81 @@ We plan to make it based on ed25519 crypto scheme and use [ecies-ed2551](https:/ * **HashAll(hash)** - get all hash fields #### Storage + * **Data Map** - mapping ipfs hashes and data keys * **Key-value** - database meta info #### Scheme 1. Palett structure + ![scheme C](https://i.postimg.cc/Hn1nkxGD/pallet.png) ##### Data uploading -- Rpc/wss request to pallet to insert data -- Validating data based on database schema -- Formatting data -- Encrypted (if needed) -- Store to ipfs via offchain::ipfs -- Retrieving ipfs hash with data -- Store ipfs hash into pallet storage +* Rpc/wss request to pallet to insert data +* Validating data based on database schema +* Formatting data +* Encrypted (if needed) +* Store to ipfs via offchain::ipfs +* Retrieving ipfs hash with data +* Store ipfs hash into pallet storage ##### Data retrieving + - RPC/wsss request to pallet to fetch get data -- Validating data query -- Get ipfs hash from storage -- Fetch data from ipfs via offchain::ipfs -- Return data object in response +* Validating data query +* Get ipfs hash from storage +* Fetch data from ipfs via offchain::ipfs +* Return data object in response #### Scheme 2. Interaction with Substrate + ![scheme D](https://i.postimg.cc/1zzJvmjQ/scheme.png) #### Infrastructure + Testing substrate nodes with offchain::orbitDB pallet orchestrated by kubernetes cluster deployed on GCP. + #### Ci/Cd + Ci/Cs organized by github actions + #### Frontend + Simple SPA web application powered by react and polkadot.js. Using for testing purposes. -### Ecosystem Fit +### Ecosystem Fit Pallet is suitable for substrate developers and strives to become a complex solution for data storage and manipulation. We expect that the project will be useful for the Web3 community. - ## Team :busts_in_silhouette: ### Team members -**Tech lead, backend:** Andrew Skurlatov +**Tech lead, backend:** Andrew Skurlatov https://www.linkedin.com/in/andrew-skurlatov/ -**Head of product:** Mike Manko +**Head of product:** Mike Manko https://www.linkedin.com/in/mikhail-manko-97a491a2/ -**Product design:** Anuar Zhumaev +**Product design:** Anuar Zhumaev https://www.linkedin.com/in/yxorama/ -**DevOps:** Ivan Podcebnev +**DevOps:** Ivan Podcebnev https://www.linkedin.com/in/naykip/ -**Data Science:** Constantine Czerniak +**Data Science:** Constantine Czerniak https://www.linkedin.com/in/%D1%81czerniak/ -**Frontend:** Nikita Velko - -https://www.linkedin.com/in/nikichv/ +**Frontend:** Nikita Velko +https://www.linkedin.com/in/nikichv/ ### Contact @@ -151,7 +164,6 @@ https://www.linkedin.com/in/nikichv/ **Contact Email:** ms@uddug.com - ### Legal Structure **Registered Address:** PO301650, RUSSIA, UL. OVRAZHNAYA, D. 35, S. TETYAKOVKA, NOVOMOSKOVSKIJ R-N, OBL. TUL'SKAYA. @@ -164,36 +176,34 @@ Core of our team is of united, like-minded professionals with solid experience. Team range of experience begins from developing small scaled websites up to complex blockchain architectures. Our projects are diverse, but all of them share the need to have a software solution for humans. - ### Team Code Repos http://github.com/andskur/ http://github.com/uddugteam/ -### Commits +### Commits https://github.com/uddugteam/thc-node/commits/master -### Related domain +### Related domain https://thc.uddug.com/ ## Development Status :open_book: -We have already developed the pre-alfa pallet for **Trusted Health Council** [(https://github.com/uddugteam/thc-node)](https://github.com/uddugteam/thc-node). +We have already developed the pre-alfa pallet for **Trusted Health Council** [(https://github.com/uddugteam/thc-node)](https://github.com/uddugteam/thc-node). Link to initial pull request (https://github.com/uddugteam/General-Grants-Program/blob/master/grants/speculative/trusted_health_consul.md). Link to 2nd pull request (https://github.com/uddugteam/Open-Grants-Program/blob/master/applications/ML-as-a-service.md). - ## Development Roadmap :nut_and_bolt: * **Total Estimated Duration:** 4 months * **Full-Time Equivalent (FTE):** 2.5 FTE * **Total Costs:** 28 000 USD -### Milestone 1 +### Milestone 1 * **Estimated Duration:** 1 month * **FTE:** 2.5 @@ -209,11 +219,10 @@ Link to 2nd pull request | 2. | Web application | Interacting with blockchain + form with fields to manipulate with data. Based on the substrate-front-end-template | | 3. | Docker image| We will provide a dockerfile to demonstrate the full functionality of testing Substrate chain with integrated Database pallet. | - ### Milestone 2 * **Estimated Duration:** 1 month -* **FTE:** 2.5 +* **FTE:** 2.5 * **Costs:** 7 000 USD | Number | Deliverable | Specification | @@ -228,7 +237,7 @@ Link to 2nd pull request ### Milestone 3 * **Estimated Duration:** 1 month -* **FTE:** 2.5 +* **FTE:** 2.5 * **Costs:** 7 000 USD | Number | Deliverable | Specification | @@ -244,7 +253,7 @@ Link to 2nd pull request ### Milestone 4 * **Estimated Duration:** 1 month -* **FTE:** 2.5 +* **FTE:** 2.5 * **Costs:** 7 000 USD | Number | Deliverable | Specification | @@ -259,7 +268,7 @@ Link to 2nd pull request ## Future Plans -Further development (adding new data storages, indexing system, concurrency queries) +Further development (adding new data storages, indexing system, concurrency queries) Community engagement diff --git a/applications/KSM-embeddable-tip-or-donate-button.md b/applications/KSM-embeddable-tip-or-donate-button.md index e2baef7e0b5..466bead9e15 100644 --- a/applications/KSM-embeddable-tip-or-donate-button.md +++ b/applications/KSM-embeddable-tip-or-donate-button.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Tip or Donate KSM Embeddable Button -- **Project:** Tip or Donate KSM Embeddable Button - **Proposer:** https://github.com/Shard-Labs - **Payment Address:** bc1q5njhr3r0mgd398yvma75nv48g69c590a0f0zcx diff --git a/applications/KZero.md b/applications/KZero.md new file mode 100644 index 00000000000..f65dce8852d --- /dev/null +++ b/applications/KZero.md @@ -0,0 +1,348 @@ +- **Team Name:** Kzero +- **Payment Details:** + - **Payment**: 167Y6kiaPzkVhYs9YM1q4bB987D4eHRLPAKgRqJpxby8Rv2f (USDC) + - **Payment**: 167Y6kiaPzkVhYs9YM1q4bB987D4eHRLPAKgRqJpxby8Rv2f (DOT) +- **Level**: 3 + +## Project Overview 📄 + +### Overview + +Kzero is a Substrate-based framework that facilitates transaction initiation on the blockchain using a **zkLogin** mechanism, enabling users to access Web3 applications without private keys. By leveraging zkSNARKs and OpenID providers, Kzero ensures seamless onboarding, on-demand key management, and high-security assurance. Any Substrate-based blockchain can easily integrate Kzero to improve user experience and adoption. + +### Background + +#### Barriers to Web3 + +- **Wallet Setup Complexity**: Traditional Web3 wallets require users to create and manage blockchain addresses, which is a daunting process for non-technical users. +- **Private Key** **Management**: Losing access to a private key results in permanent loss of funds, making users reluctant to engage with Web3 applications. +- **Mnemonic Phrases Burden**: Users are required to store and secure a 12 or 24-word seed phrase, which introduces the risk of human error and phishing attacks. + +It's worth observing that all these features and plans are wallet-related challenges and solutions. + +#### Current wallet Solution + +There are already various wallet solutions available, each catering to different security and usability needs. For example, hardware wallets offer high security but lack ease of use, while MPC wallets are highly user-friendly but come with certain security risks. + +![Wallet Solutions](https://p.ipic.vip/ur1zop.png) + +### ZKLogin is the ultimate solution + +zkLogin brings several key advantages to blockchain authentication: + +- **Enhanced Security**: Unlike traditional private key management, zkLogin ensures authentication without exposing sensitive credentials, reducing phishing and key theft risks. +- **Improved Privacy**: By leveraging zero-knowledge proofs, zkLogin allows users to authenticate without revealing unnecessary personal information to third parties. +- **Seamless User Experience**: zkLogin eliminates complex onboarding processes, enabling users to access Web3 applications with familiar social logins. +- **Interoperability**: zkLogin can be easily integrated with multiple blockchain networks, making it a flexible and scalable authentication solution for the Web3 ecosystem. +- **Resistance to Account Compromise**: Even if an ephemeral key is compromised, the user's main account remains secure, providing an extra layer of protection. + +*Leading ecosystems are already actively researching zkLogin.* + +| | Support zkLogin? | Proof | Solutions | +| -------- | ---------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| Ethereum | ❓ | https://ethresear.ch/t/zklogin-framework-based-on-4337-contract-wallet/20855 | [Privy](https://x.com/0xJamesXXX/status/1831663721024012621)[Dynamic](https://app.dynamic.xyz/) | +| Sui | ✅ | https://sui.io/zklogin | [Sui Wallet](https://suiwallet.com/) | +| Starknet | ✅ | https://mirror.xyz/xarlabs.eth/kfUf0XyK-sxig3DYBKvVcr836HEyvkqqxU0uN-tjAHo | [zKey](https://www.zkey.org/) | +| Aptos | ✅ | https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-61.md | [Keyless Wallet](https://aptos.dev/en/build/guides/aptos-keyless) | + +Some of the products attract millions of people, [like Privy](https://bingx.com/zh-tc/support/articles/36563397225497/), is important to the Polkadot ecosystem as well. + + + +## Highlights of KZero + +- **Keyless:** Say goodbye to managing private keys. One-click access to your DAppswithout keys or device dependency. Simple, fast, and frictionless. +- **100% Self-Custodial:** Users maintain complete ownership of their assets — your data stays with you. Maximum security for your assets and identity, always under your control. +- **Maximum Security Assurance:** Kzero introduces a revolutionary approach to key management, empowering users to seamlessly change their local temporary private keys at their convenience while providing the option to set expiration times for each key. +- **Simplified Onboarding:** One-click seamless experience. Users can initiate the onboarding process with a single click by choosing to "Login with Google," after that, users can easily start to submit transactions. +- **ZKP-based Social Login.** **Privacy Protected:** Zero-knowledge proof (ZKP) lets users interact with Web3 while keeping their data private. No compromises—access DApps securely and anonymously. +- **Multiple** **JWT** **providers:** Users can login with Google, Twitch, Kakao, Facebook, Apple, Slack and other OpenID Providers. + + + +## Tech Details + +### How Kzero works + +![zklogin-mechanism](https://p.ipic.vip/9ppk9h.png) + +(Step 0) We plan to use Groth16 for our protocol’s zkSNARK instantiation, requiring a singular generation of a structured common reference string (CRS) linked to the circuit. A ceremony is conducted to generate the CRS, which is used to produce the proving key in the ZK Proving Service, the verifying key in Project Authority. + +(Step 1-3) The user begins by logging into an OpenID Provider (OP) to obtain a JWT token containing a defined nonce. In particular, the user generates an ephemeral KeyPair (eph_sk, eph_pk), along with expiry times (max_epoch) and randomness (jwt_randomness). Through these three parameters, the Wallet Extension can thus compute the nonce. After the user completes the OAuth login flow with the nonce, an JWT token can be retrieved. + +(Step 4-5) The Account Related Module then sends the JWT token to a Salt Backup Service which returns the unique user_salt based on the JWT token. + +(Step 6) The Wallet Extension sends the ZK Generation Service with the JWT token and some auxiliary inputs. The proving service generates a Zero-Knowledge Proof that takes these as private inputs and does the following: a) Checks the nonce is derived correctly as defined b) Checks that key claim value matches the corresponding field in the JWT, c) Verifies the RSA signature from OP on the JWT, and d) the address is consistent with the key claim value and user salt. + +(Step 7) A transaction is signed using the ephemeral private key to generate an ephemeral signature. Finally, the user submits the transaction along with the ephemeral signature, ZK proof and other inputs to Chain. + +(After Step 7) After submitted on chain, the Kzero framework verifies the ZK proof against the provider JWKs from storage (agreed upon in consensus) and also the ephemeral signature. + +### Components + +**ZKP Service** + +Responsible for generating zero-knowledge proofs. This includes two submodules: the zk circuit and the ZKP generation module. + +> The ZK Circuit should contain the following main checks: +> +> ( a ) Checks the nonce is derived correctly as defined +> +> ( b ) Checks that key claim value matches the corresponding field in the JWT, +> +> ( c ) Verifies the RSA signature from OP on the JWT, +> +> ( d ) Check the address is consistent with the key claim value and user salt. + +The generation of zero-knowledge proofs will occur on the server side, rather than the client side, to enhance user experience. The service will be accelerated using GPUs. + +**Salt Service** + +When signing a transaction for an address using Kzero, a **unique salt** value must be provided. This salt value is crucial for ensuring that onchain addresses cannot be traced back to the user’s Web2 credentials. + +**KZero-SDK** + +Functionalities: + +1. Full-Flow zkLogin Implementation + 1. Handles the complete zkLogin workflow, including: + - JWT request management + - Secure salt generation + - Zero-Knowledge Proof (ZKP) generation (server-side GPU-accelerated) +2. Third-Party Integration Service + 1. Provides out-of-the-box zkLogin support for external applications. + 2. Once integrated, third-party applications can seamlessly enable zkLogin functionality. + +**Zklogin-runtime** + +This is a Substrate runtime pallet that: + +1. verifies zklogin-format extrinsics +2. verifies zero-knowledger proofs +3. maintains valid JWK sets + + + +### KZero Workflow + +![KZero workflow](https://p.ipic.vip/5vptx2.png) + +In short, the Kzero process can be broken down into the following steps + +1. The user generates an ephemeral keypair locally, ensuring that it has a set expiration time for higher security. This keypair is used for signing the zkLogin transaction later. +2. The user authenticates their identity via a social account, after which they retrieve a signed JSON Web Token (JWT) as proof of authentication. +3. Utilizing the salt service, the user communicates with the salt server. After verifying their identity through the JWT, they obtain the unique salt associated with their zkAccount, which is essential for the ZKP Generation process and on-chain address calculation. +4. Utilizing ZKP generation service to efficiently and securely generate zero-knowledge proof, ensuring privacy and security without exposing sensitive information. +5. Finally, the user assembles the zkLogin transaction, signs it using the ephemeral keypair generated earlier, and then sends the signed transaction to the blockchain for verification, ensuring a secure and seamless login process. + + + +### Recovery Mechanisms + +There are currently two potential, optional recovery mechanisms available: + +1. **Built-in recovery mechanism in zklogin-pallet**: Each zklogin address can designate a recoverer. Under specific conditions, such as when a zklogin address has been inactive for N hours, the recoverer can send transactions and manage assets on behalf of the zklogin address. +2. **zklogin + proxy**: Through the proxy pallet, a zklogin address can set up 'delegate' or 'delayed-delegate' accounts. At any time when assets in the zklogin address face potential threats, users can immediately handle their assets securely through the proxy module. + +mechanism 1 will be implemented within the scope of this grant. + + +## Security and Privacy + +**Ephemeral Private Key** + +The ephemeral private key remains valid only before the expiration time. If this key is lost, users can simply generate a new ephemeral private key for signing transactions, along with a new ZK proof. However, in cases where the temporary private key is compromised, attackers would still need both the user's salt and a valid ZK proof to access and transfer funds. + +The ephemeral private key is stored in the browser's **session storage**, which means that: + +- Maintains data only for the duration of a browser session +- Automatically clears when the browser tab or window is closed +- Is isolated to a single browser tab/window +- Provides better security compared to Local Storage for sensitive data +- Data is never transferred to the server + + + +**User Salt** + +The user salt plays a vital role in both: + +- generating ZK proofs +- deriving zkLogin addresses + +While a compromised user salt alone doesn't directly threaten funds, it does create privacy implications. An attacker with access to the user salt could link a user's subject identifier (sub) to their zkLogin address. + + + +**Salt Server** + +The salt server leverages a master seed along with the user's JSON Web Token (JWT) to derive a reproducible salt value for each user and application. The security of the master seed and the derivation algorithm is critical, so the entire computation is executed in a secure environment, such as a Trusted Execution Environment (TEE). This setup ensures that the master seed, which is critically important, is generated within a trusted environment, preventing even administrators from accessing it. + +To address potential disaster scenarios, the master seed is divided into multiple encrypted shards. These shards are distributed to a Salt Value Committee, which may consist of community-selected members or esteemed entities like Parity Technologies, the Web3 Foundation, and others. This approach enhances resilience and ensures that no single entity has complete control over the master seed, thus maintaining the integrity and security of the identity-to-address separation. + + + +## Ecosystem Fit + +Kzero provides significant advantages to the Polkadot and Kusama ecosystems by improving accessibility, security, and usability. Key benefits include: + +- **Enhanced User Adoption**: By eliminating the need for complex private key management, Kzero lowers the entry barrier for new users, driving higher adoption across Polkadot and Kusama projects. +- **Improved UX for DApps**: Web3 applications can integrate Kzero to offer seamless authentication without sacrificing decentralization. +- **Security and Compliance**: The use of zero-knowledge proofs ensures that user authentication remains private and verifiable, aligning with Polkadot’s principles of security and interoperability. +- **Compatibility** **with Multiple Chains**: Any Substrate-based chain can integrate this pallet to provide a social login feature, making it a valuable addition to the ecosystem. + + + +# Team 👥 + +### Team members + +- Leader: Liam Xu +- Members: Suvi Dong(Runtime Engineer), Jarvan Zhang(Full-Stack), Tiny Liu(PM) + +### Contact + +- **Contact Name:** Dev team +- **Contact Email:** dev@kzero.xyz +- **Website:** https://kzero.xyz/ + +### Legal Structure + +- Start up team + +### Team's experience + +**Liam Xu**: Math and computer science background. Over four years of research experience in the zero-knowledge field, familiar with various zk algorithms and tools. Translated and analyzed multiple zk-related articles. Worked in the blockchain industry for 3+ years, with expertise in ecosystems such as Ethereum, Solana, Polkadot, etc. Good at Rust, Solidity, Node.js, and Anchor development. + +**Suvi** **Dong**: Suvi previously worked with Darwinia team as smart contract developer and runtime developer, currently serving as a graduate-level blockchain course lecturer at NUAA (Nanjing University of Aeronautics and Astronautics, ranked top 30 in China). + +**Jarvan Zhang:** Jarvan with five years of experience in the blockchain industry, has served as a front-end development engineer at 8BTC and a full-stack development engineer at Patract. + +**Tiny Liu:** Tiny previously worked with the Darwinia team as the project lead for a blockchain game helping the project achieve a DAU (Daily Active Users) breakthrough. + +### Team Code Repos + +Team github: + +- [https://github.com/kzero-xyz](https://github.com/kzero-xyz) + +# Development Status 📖 + +- ✅ Complete the ZK circuit design. +- ✅ Complete the on-chain rule design. + +# Development Roadmap 🔩 + +## Overview + +- **Total Estimated Duration:** 2 Months +- **Full-Time Equivalent** (FTE): 4 FTE +- **Total Costs:** 50,000 USD +- **DOT %**: 50% + +Milestone 1: ZKP Service + +> The ZKP-related tasks include the **ZK** **Circuit Code** (written in Circom), the **ZKP witness service**, and the **ZKP generation service**. The key logic for the circuit can be found in the "component" section. To generate the zero-knowledge proof based on the ZK circuit, the process starts with witness generation(https://docs.circom.io/background/background/#witness), followed by the generation of the zero-knowledge proof via the witness. To enhance performance and provide a better experience, the **ZKP generation service** will utilize a **GPU-based** version. + +- **Estimated duration:** 1 month +- **FTE**: 4 +- **Costs:** 20,000 USD + +| Number | Deliverable | Specification | +| ------ | ------------------------- | ------------------------------------------------------------ | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide technical documentation for the code, as well as deployment and testing guides, explaining key function calls and how users can start and test our ZKP-related server, which will demonstrate how it works. | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1 | Kzero Circuit Code | We will provide an open-source repository, release the circuit code, and offer comments, design insights, and documentation to help with understanding. We will also provide test code for the circuit and usage documentation to allow users to perform local testing. | +| 2 | ZKP Witness Service | We will provide the repository for the ZKP Witness Service, along with service guide and testing documentation. | +| 3 | ZKP service (GPU) | We will provide the repository for the ZKP Generation Service(GPU-Version), along with service guide and testing documentation. | + +## Milestone 2: kzero-runtime + +- **Estimated Duration:** 1 month +- **FTE**: 4 +- **Costs:** 20,000 USD + +This part serves as substrate runtime pallets, consists of two main components: + +1. pallet-zklogin + 1. Transaction entry points for ZK operations + 2. Transaction verification workflow + 3. Maintenance of valid JWK (JSON Web Key) set + 4. Recovery mechanism +2. primitive-zklogin + 1. Core type definitions for zkLogin + 2. Zero-knowledge proof verification components + 3. Utility functions and helpers + +| Number | Deliverable | Specification | +| ------ | ------------------------- | ------------------------------------------------------------ | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1 | kzero-runtime | open source repo | +| 2 | Tests | tests on pallet-zklogin and primitive-zklogin | +| 3 | docs | A tutorial for how to integrate Kzero into a substrate-based blockchain | + +## Milestone 3: Salt Service + +> The architecture of the Salt Server is critical, as it introduces a value to unlink the OAuth identifier from the on-chain address. We have chosen to implement a Trusted Execution Environment (TEE), running the Salt Server in an isolated environment to ensure that only the user can access their salt, preventing any unauthorized access. + +- **Estimated Duration:** 0.5 month +- **FTE**: 2 +- **Costs:** 5,000 USD + +| Number | Deliverable | Specification | +| ------ | ------------------------- | ------------------------------------------------------------ | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1 | Salt Service Code | We will provide the repository for the Salt Service, along with service guide and testing documentation. | +| 2 | docs | A tutorial for how to use the Salt Service. | + +## Milestone 4: KZero-SDK + +> Milestone Focus: +> +> In this milestone, we will deliver the basic functionalities of the kZero-SDK, including: +> +> - A demo website that offers an experiential zkLogin service. +> - Note: This milestone does not include the module for integration with third-party applications. + +- **Estimated Duration:** 0.5 month +- **FTE**: 2 +- **Costs:** 5,000 USD + +| Number | Deliverable | Specification | +| ------ | ------------------------- | ------------------------------------------------------------ | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide technical documentation for the SDK. | +| 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 overviewing using Fennel Protocol in applications for secure off-chain data-centric messaging and secure on-chain signal mechanisms. | +| 1 | Kzero-SDK | We will provide an SDK repository that covers all functionalities, from account creation to transaction submission using Kzero, along with detailed comments and documentation for better understanding. | +| 2 | Kzero-Website | We will provide a demo website for Kzero, which will include essential account and transaction features. | + +## Future Plans + +1. Third-Party Integration SDK + 1. Release a comprehensive SDK for seamless third-party application integration. +2. Enhanced KZero Runtime + 1. Expand and optimize the KZero runtime to support eth-compatible transaction formats, enabling compatibility with the Asset Hub. +3. KZero Developer Platform + 1. Securely serves third-party applications, and provide detailed user data analytics and insights to support apps' needs. +4. zkLogin Notification Service + 1. A notification service for third-party applications based on zklogin. + +## Additional Information ➕ + +**How did you hear about the Grants Program?** + +Hear from Seraya. + +**Demo Website:** + +https://demo.kzero.xyz/ \ No newline at end of file diff --git a/applications/Knowledge-Oriented-Framework.md b/applications/Knowledge-Oriented-Framework.md new file mode 100644 index 00000000000..cc8338074ae --- /dev/null +++ b/applications/Knowledge-Oriented-Framework.md @@ -0,0 +1,265 @@ +# A Knowledge-Oriented Approach to Enhance Integration and Communicability in the Polkadot Ecosystem + +- **Team Name:** MOBR Systems + +- **Payment Address:** 0x504779E1d616Ff75aFA0D4417bc2A5cCB678c671 (USDC) + +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +This project is an R&D initiative towards enhancing integration and communicability in the Polkadot ecosystem. The first step encompasses a theoretical contribution to map, structure and formalize Polkadot's multi-chain environment concepts and relationships, by adopting an ontological approach. Afterwards, we expect this ontological framework to be applied on the building of a controlled natural language (CNL) and a querying engine for the Polkadot ecosystem. + +Ontologies represent concepts and relationships in a manner that approximate the way humans perceive interconnected abstractions, while promoting machine reasoning on top of that representation to offer insights to users, developers and intelligent applications. In addition to supporting reasoning capability, ontologies provide a coherent and easy interpretation, enhancing communication in the ecosystem. They allow users to navigate from one concept to another, supporting the current understanding about the fundamentals of the modeled domain, and also its natural expansion. The R&D process and contributions will be documented in a scientific paper and an ontology representation. Both will be publicly available on github. + + +Initially, the proposed ontology will focus on the Polkadot multi-chain environment to identify, describe and relate core concepts of the technology. That is, we will create a conceptual framework that represents the ecosystem behind Polkadot, including parachains, nodes, transaction settlement, cross-chain communication, assets, primitives, etc. With the fundamental aspects defined, it would be possible to expand the ontology to model the concepts and relationships between the Substrate blockchain framework and Polkadot’s canary network, Kusama. + + +Moving forward with the state-of-the-art and innovation that tackles real issues is what inspires the MOBR team. As an R&D-oriented startup, we target research opportunities where we can apply AI in a user-centric approach. As Web3 developers and enthusiasts, we are always looking for potential improvements for the technology and its community. The lack of a formal definition and terminology for blockchain environments is an open issue, since it remains open to interpretation and does not offer a consistent representation for its developers, users, and applications. + +### Project Details + +- The problem + +There is no doubt that the Polkadot's multi-chain environment is a highly disruptive platform. However, the lack of a formal definition of its terminology is an issue since it remains open to interpretation and does not offer a structured representation for its applications. Currently, Polkadot literature is predominantly written either from a purely technical or from an economical perspective. Aiming at supporting the growth of the Polkadot community in both formal knowledge and applications, it is critical that users, developers, and stakeholders have a formal and fundamental understanding on how the platform is built and how it works. Without such formal representation, application developers may struggle to integrate software components and data, as well as to build querying and reasoning features in a standardized manner. Unstructured development combined with lack of expressiveness about the ecosystem may jeopardize interoperation and wide adoption of Polkadot, especially in heterogeneous socio-technical environments. + +- Research questions/hypothesis + +The general research question we want to answer is: how a knowledge-oriented approach may benefit the communicability, integration, usage and development of blockchains? + +And more specifically, how an ontology-supported development impacts design and building of Polkadot’s parachains and cross-chain communication? + +- The methodology + +Our approach will begin by conducting a comprehensive literature review to identify key concepts and principles in ontologies for blockchains. This includes studying the existing applications and ontological frameworks that have been developed for blockchains, as well as other relevant research in the fields of symbolic representation. Once the key concepts and principles have been identified, the next step is to create a conceptual framework that incorporates and relates these concepts and principles. This framework will be designed to express the fundamental entities and relationships that govern the Polkadot ecosystem, and will be flexible enough to accommodate the ongoing evolution of the technology. With the conceptual framework specified, the next step will be applying it to a specific Polkadot-related use case scenario. This includes conducting case studies to explore the future application of the ontological framework to support the building of a controlled natural language (CNL) and a querying engine in Polkadot's multi-chain environment. Another important aspect of creating an ontology is to engage with experts from application domains to gain their insights and perspectives. This engagement helps to ensure that the ontological framework is grounded in real-world experience and reflects the current understanding of representative personas in the applied fields. In this sense, the final step of the proposed approach is to present and discuss the ontology with members of the Polkadot team. + +- Data collection and analysis procedures + +An ontology is a representation of a set of concepts within a domain and the relationships between those concepts. The data collection consists in the search for relevant concepts and their relationships. The initial data for defining the basics of the ontology will be collected through analysis of the available literature, including technical reports from Polkadot documentation. The engagement with the Polkadot team will also produce valuable data to be collected and analyzed. During the consolidation of the basic ontology, analysis will be carried out qualitatively. In the future, after having a consolidated ontology, dynamic tests can be developed to assess more quantitative aspects regarding the coverage of the formal definition. + +- Expected results + +The main expected result is an ontology representing the fundamental entities and relationships that govern the Polkadot ecosystem. We will work with the grants team to conduct a qualitative analysis to assess the correctness of the model. + +- Relevant related work + +Researchers have been exploring the potential applications and support of ontology to the field of blockchain and DApps in general. For example, ontology has been used to study the concept of trust in blockchain systems, to develop more robust and secure smart contract systems, and to address potential ethical and philosophical issues in the use of blockchain technology [1, 2, 3]. + +Currently, blockchain literature is predominantly written either from a purely technical or from an economic perspective. The use of ontologies in blockchain is an emerging field with significant potential for bridging both technical and economic perspectives, advancing the understanding of this technology while improving its design and use. Research is needed to better explore the potential use cases and applications on top of formal ontologies and to develop a comprehensive ontological framework for this type of technology. + +[1] Besançon, L., Da Silva, C. F., Ghodous, P., & Gelas, J. P. (2022). A Blockchain Ontology for DApps Development. IEEE Access, 10, 49905-49933. + +[2] Hang, L., Chen, C., Zhang, L., & Yang, J. (2022). Blockchain for applications of clinical trials: Taxonomy, challenges, and future directions. IET Communications. + +[3] Baqa, Hamza & Truong, Nguyen & Crespi, Noel & Lee, Gyu Myoung & Le Gall, Franck. (2019). Semantic Smart Contracts for Blockchain-based Services in the Internet of Things. 1-5. 10.1109/NCA.2019.8935016. + + +- Intended venue for results publication and the timeline for publication + +We deem the proposed work would be a good fit for venues such as the following: + +International Congress on Blockchain and Applications (ICBA) + +IEEE International Conference on Blockchain and Cryptocurrency (ICBC) + +International Semantic Web Conference (ISWC) + +In terms of timeline, and considering 4 months of project, it will depend on the dates for these venues. + +For the ISWC 2023, the dates are still TBD. But considering the 2022 calendar, it would be possible to submit by Q2-Q3 and publish by Q3-Q4 in 2023. + +For the ICBA 2024, the submission would be at Mar/2024 and the publication would be around July 2025. + +For the ICBC 2024, the submission would be at Dec/2023 and the publication would be around May/2024 + + +- What the project is _not_ or will _not_ provide or implement + +Our research proposal is a first-step towards creating a rich and convenient asset for performing query searching and data analytics on the Polkadot's multi-chain environment. For now, we are proposing a conceptual model that will be capable of formalizing the key Polkadot concepts and their relationships. In this proposal we are not considering the development and deployment of any functional asset or prototype, but specifically the ontology representation and a case study to explore the future application of the ontological framework to support building a controlled natural language (CNL) and a query engine in Polkadot’s multi-chain ecosystem. + +### Ecosystem Fit + +As mentioned, the proposed ontology will focus on the Polkadot multi-chain environment to identify, describe and relate core concepts of the technology. That is, we will create a conceptual framework that represents the ecosystem behind Polkadot, including parachains, nodes, transaction settlement, cross-chain communication, assets, primitives, etc. With the fundamental aspects defined, it would be possible to expand the ontology to model the concepts and relationships between the Substrate blockchain framework and Polkadot’s canary network, Kusama. + +- Target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? + +The target audience is the Web3 community in general, and those specifically interested in the Polkadot multi-chain ecosystem, since we will provide a formal definition of the Polkadot terminology. + +- What need(s) does your project meet? + +At first, the need for a formal definition addressing the issue of having a terminology open to interpretation or that does not offer a structured representation for its applications. In the future, the project will allow ecosystem users and developers to retrieve and manipulate data from Polkadot using a controlled natural language. That is, users will be able to intuitively and correctly specify their queries. For instance: How many transactions were carried out for the past 30 min on all parachains? What are the top five wallets with DOT tokens? How many wallets have more DOT tokens than me? What is the total NFT sales volume on the Polkadot ecosystem? + +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? + +To the best of our knowledge, there is no similar project in the ecosystem using a knowledge-oriented approach to support CNL querying. Currently, users without programming skills depend on blockchain explorers to have access to chain data. There is a lack of solutions providing natural language querying. + +There is a project [1] providing querying capabilities on Polkadot. +[1] https://academy.subquery.network/ + +In addition, there is no formal ontology currently specified and maintained for the ecosystem. + + - If so, how is your project different? + +The SubQuery project uses GraphQL and does not support querying specific concepts inherent from the ecosystem. However, as mentioned this project demands programming skills from its users. + + - If not, are there similar projects in related ecosystems? + +Specifically regarding our first step for defining a formal ontology, there is the EthOn project, which is an Ethereum Ontology described in http://ethon.consensys.net + +Concerning the query-answering asset using CNL, there is no similar project in related ecosystems, as far as we know. + +## Team :busts_in_silhouette: + +### Team members + +- Name of team leader +**Dr. Marcio Moreno**, marcio@mobr.ai, Co-Founder, Research Scientist and CEO at MOBR Systems (https://www.mobr.ai). + +- Names of team members +**Dr. Rafael Brandao**, rafael@mobr.ai, Co-Founder, Research Scientist and COO at MOBR Systems (https://www.mobr.ai). + +### Contact + +- **Contact Name:** Marcio Ferreira Moreno + +- **Contact Email:** marcio@mobr.ai + +- **Website:** https://www.mobr.ai + +### Legal Structure + +- **Registered Address:** +Av Paulista, 1106 Sala 01 / ANDAR 16 - Bairro: Bela Vista, Sao Paulo - SP CEP 01310914 + +- **Registered Legal Entity:** +MOBR SYSTEMS LTDA + +### Team's experience + +Both applicants worked as Research Scientists at IBM for 7 years. Earlier, Dr. Moreno (full CV on [1]) was a postdoctoral researcher at CWI (Centrum Wiskunde & Informatica) in the Netherlands, and worked at the Pontifical Catholic University of Rio (PUC-Rio) in Brazil. Dr. Brandão (full CV on [2]) worked at the TecGraf Institute, from PUC-Rio, during his doctoral studies. The team has published multiple research papers and patents, their background includes Web3, AI, Knowledge Engineering, Distributed and Decentralized Systems, Multimedia and Hypermedia Systems, Human-Centered Computing, among other research topics. + +For a complete list of peer-reviewed published papers and granted patents, please visit the following google scholar links + +- Marcio Moreno, PhD: https://scholar.google.com/citations?user=PfdmrPUAAAAJ +- Rafael Brandao, PhD: https://scholar.google.com/citations?user=3ta0InEAAAAJ + +### Team Code Repos + +MOBR Systems: +- https://github.com/mobr-ai + +Our personal accounts: +- https://github.com/mfmoreno +- https://github.com/rbrandao + + +### Team LinkedIn Profiles (if available) + +- https://linkedin.com/in/marcio-moreno-phd-598a459a/ +- https://linkedin.com/in/rafaelrmb/ + +### Google Scholar Profiles (Or other research indexer profile, ex. Researchgate) +- https://scholar.google.com/citations?user=PfdmrPUAAAAJ +- https://scholar.google.com/citations?user=3ta0InEAAAAJ + +## Development Status :open_book: + +Not initiated yet. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** We expect to conclude the proposed first step of the project in 4 months + +- **Full-Time Equivalent (FTE):** 1 FTE (two PhDs each dedicating about 30 days of work during a 4 months project) + +- **Total Costs:** The total budget requested is US$ 29900 for two PhDs dedicating about 30 days of work during a 4 months project. Considering that for academic, scientific, consultancy on average a PhD daily rate is about US$500. + +### Milestone 1 — Literature review and conceptual framework specification + +Our approach will begin by conducting a comprehensive literature review to identify key concepts and principles in ontologies for blockchains. This includes studying the existing applications and ontological frameworks that have been developed for blockchain systems, as well as other relevant research in the fields of symbolic representation + +Once the key concepts and principles have been identified, the next step is to specify a conceptual framework that incorporates and relates these concepts and principles. This framework will be designed to express the fundamental entities and relationships that govern the Polkadot ecosystem, and it will be flexible enough to accommodate the ongoing evolution of the technology. + +- **Estimated Duration:** 2 months +- **FTE:** 1 +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | Copyright and Licenses | MIT | +| **0b.** | Documentation/Tutorial | We will provide a PDF document identifying and reviewing related work, concepts and principles in blockchain ontologies. For the ontology, the specification will be delivered as an OWL file with formal description of the Polkadot ecosystem abstractions. | +| **0c.** | Methodology | PDF document detailing how we carried out a systematic review of related blockchain ontologies, and the correlation with the main abstractions of Polkadot's conceptual framework. | +| **0d.** | Infrastructure | We will provide the list of all infrastructure requirements (text editors with proper versions, software packages, data packages, etc) that can be used to verify the deliveries with this milestone. | +| **0e.** | Article | We will write a draft **article** (along with source code) explaining what was achieved in this milestone. | +| **1.** | Literature survey | Document identifying and reviewing related work, concepts and principles in blockchain ontologies | +| **2.** | Conceptual framework | Ontology in OWL format with formal description of the Polkadot ecosystem| + + +### Milestone #2 – Case study for query engine + +With the conceptual framework specified and developed, the next step will be applying it to a specific Polkadot-related use case scenario. This includes conducting a case study to explore the future application of the ontological framework to support building a controlled natural language (CNL) and a query engine in Polkadot’s multi-chain ecosystem. + +- **Estimated Duration:** 1 month +- **FTE:** 1 +- **Costs:** 8,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | Copyright and Licenses | Unlicense | +| **0b.** | Documentation/Tutorial | We will provide a PDF document describing a use case to the future application of the ontological framework supporting the building of a controlled natural language (CNL) and a querying engine in Polkadot's multi-chain environment. | +| **0c.** | Methodology | The use case will be developed based on our expert perspective and also requirements identified from the engagement with other blockchain experts. That is, the requirements for the query engine will be grounded in real-world experience needs. | +| **0d.** | Infrastructure | We will provide the list of all infrastructure requirements (text editors with proper versions, software packages, data packages, etc) that can be used to verify the deliveries with this milestone. | +| **0e.** | Article | We will write a draft **article** explaining what was achieved in this milestone. | +| **1.** | Case study | Document describing case study on conceptual framework application with query engine | + +### Milestone #3 – Polkadot team brainstorming / workshop + +An important aspect of creating an ontology is to engage with experts from application domains to gain their insights and perspectives. This engagement helps to ensure that the ontological framework is grounded in real-world experience and reflects the current understanding of representative personas in the applied fields. In this sense, a key step of the proposed approach is to present and discuss the ontology with the Polkadot team. + +- **Estimated Duration:** 1 month +- **FTE:** 1 +- **Costs:** 6,900 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | Copyright and Licenses | CC BY 4.0 | +| **0b.** | Documentation/Tutorial | We will provide two PDF documents, one reporting scientific and technical findings and the other presenting reflections over the discussed content and action items | +| **0c.** | Methodology | The methodology for the team discussion will be loosely based on a Design Thinking process. We will guide the team during discussion in order to extract relevant feedback from experts. The idea is to carry this activity remotely. | +| **0d.** | Infrastructure | We will suggest tool options for carrying out the collab session. That can be Mural or other equivalent free cloud collaborative tool available (e.g. Google Drive, MS Teams).| +| **0e.** | Article | We will write a full **article** detailing what was achieved in the project. The article will have an acknowledgment in the body of it stating the research was supported by Web3 Foundation. It will be public available on arXiv.org and submited to listed scientific venues | +| **1.** | Presentation deck | Slide deck with reflections over the discussed content and action items| + + + + +## Future Plans + +- Our intention is that the conceptual framework constructed during the proposed research be used to support future knowledge-oriented assets. That is, assets that can take advantage of the Polkadot ecosystem’s formal definition, producing new knowledge, consuming it, and performing reasoning procedures. + +- In the short term, we will provide a case study for bootstrapping use cases to guide the design and building of a query engine tool. This asset will provide semantic searching features based on a controlled natural language (CNL). + +- The development roadmap for such an asset would be the long term plan related to this project proposal. Which would enrich the user experience within the Polkadot community. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Web3 Foundation Website + +- Work already done + +We have work in progress assets being developed in our recently founded startup. More info can be found at: https://mobr.ai + +We also previously developed a technology that became widely adopted within IBM Research. It is a toolset to deal with knowledge engineering and ontology construction. More info can be found here: +1. https://github.com/ibm-hyperknowledge +2. https://ibm-hyperknowledge.github.io/possibility-link-demo-iswc2022/ + +- Previous applied grants + +We have already submited proposals to Waves and VeChain grant programs. + diff --git a/applications/Koiverse.md b/applications/Koiverse.md index 58cd2578cf8..0b8356594a3 100644 --- a/applications/Koiverse.md +++ b/applications/Koiverse.md @@ -1,52 +1,39 @@ -# Koi Metaverse - Open Grants Program +# Koi Metaverse - - -* **Project:** Koi Metaverse * **Proposer:** https://github.com/KoiMetaverse * **Payment Address:** 0xfADc3c36E41D36796ca05B4D55b148725c804cE0 - +* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/678#issuecomment-1204360469) # Project Overview - ## Overview - ### Introduction -Koi Metaverse aims to unlock the next-gen GameFi metaverse economies and it is building the digital collectibles platform for virtual GameFi NFTs. It is a fish collection blockchain game that combines token economy and NFT assets. It consists of a series of smart contracts, and all of the in-game assets belong to its players. Players can play to earn by collecting high mining power fish and growing them, creating a positive self-circulation. +Koi Metaverse aims to unlock the next-gen GameFi metaverse economies and it is building the digital collectibles platform for virtual GameFi NFTs. It is a fish collection blockchain game that combines token economy and NFT assets. It consists of a series of smart contracts, and all of the in-game assets belong to its players. Players can play to earn by collecting high mining power fish and growing them, creating a positive self-circulation. If pure-bred mining fish is reproduced, you can lock it into the pictorial book to mine the governance token, and use it to participate in the other DeFi activities. Koiverse creates a variety of NFT assets in the form of fish images and aims to become the BearBrick in the blockchain GameFi space and the brand new Axie Infinity on the Polkadot network. - ### Team Interest Our team has more than 10 years of game development experience and 3 years of blockchain game development experience. The number of accumulated registered users in the previous games is over 50 million globally. The highest number of active unique users exceeded 1 million. Koi team is also experts in innovative gaming mechanisms, sidechain implementation, tokenization economics and decentralized wallet integration. We are creating new kinds of virtual assets on Blockchain. Certainly we are the true Metaverse believers and builders who have strong motivation to unlock the Next-Gen GameFi Metaverse Economies. In Metaverse powered by Blockchain, we have seen the following core disruptive innovations: - - * Blockchain infrastructure leads to the property rights revolution. With blockchain, we can imagine a world in which contracts are embedded in digital code and stored in transparent, shared databases so that everyone could have the real ownership of properties. * Non-Fungible Token (NFT) changes the types and rules of games. NFT is a new form of unique digital asset designed to show someone has ownership of a unique virtual asset. It will become a new trend of virtual assets for creating, trading and collecting. * Tokenization and crypto creates brand-new business models. Crypto unlocks new rules of business models in game, like the concept of Play-to-Earn (P2E) which created new types of jobs and professions in digital Metaverse economies. - ## Project Details - ### Project Architecture The technical architecture of the project: ![](https://statics.fishnft.xyz/github/koi.png) - The gaming NFT protocols and Dapp consists of: - - * NFT Lottery Draw (NFT function) * NFT Auction Sale (NFT function) * NFT Minting (NFT function) @@ -56,51 +43,38 @@ The gaming NFT protocols and Dapp consists of: * Fish Mining (game function) * Pictorial Book Mining (game function) - #### NFT Functions **NFT Lottery Draw** - ### Types - - * `name` - activity name * `nft` - nft contract address * `noin` - coin contract address * `price` - fees needed to run lottery -* `total` - total number of lotteries +* `total` - total number of lotteries * `remain` - remnant quantity -* `limit` - nft limited per person -* `startTime` - activity start time +* `limit` - nft limited per person +* `startTime` - activity start time * `endTime` - activity end time - ### Functions - - * `lottery()` - lottery **NFT Auction Sale** - ### Types - - * `name` - activity name * `nft` - nft contract address * `coin` - coin contract address * `startTime` - activity start time * `endTime` - activity end time - ### Function - - * `fishList()` - read the fish list in the auction activity * `fishGeneList()` - read the fish gene list in the auction activity * `bid()` - users submit bids @@ -109,21 +83,15 @@ The gaming NFT protocols and Dapp consists of: **NFT Minting** - ### Types - - * `nft` - nft contract address * `coin` - coin contract address * `totalNft` - current NFT quantities in mining pool * `totalNftPower` - current total NFT mining power in mining pool - ### Function - - * `myNft()` - read staked NFT * `getNft()` - read one nft info * `earned()` - read mining profit @@ -132,80 +100,58 @@ The gaming NFT protocols and Dapp consists of: * `withdrawNftAll()` - withdraw all staked nfts * `getReward()` - acquire mining reward - #### NFT Assets **Fish NFT** - - * Each fish is composed of 14 genetic components: shape, color, pattern, eyes, mouth, pectoral fin, dorsal fin, caudal fin, decorations, invisible components, and breeding sequence. * The highest mining power of the fish is determined by the sum of each part’s mining power, gear buff, and the cultivation level. * When certain fish genes match, a mining power bonus and pictorial books will be activated. **Fist Tank NFT** - - * The fish can grow up in fish tanks. The cultivation time cycles are 10 days, 30 days, and 90 days, which respectively come with a maximum 30%, 120%, and 400% mining power increase. * Each fish tank may have unique features and different capacities. * Fish tanks and fish cannot be sold during the lock period. * In the cultivation time, the fish cannot engage in mining or breeding. - #### Game Functions **Fish Breeding** - - * The only way gamers can mint new fish NFT assets is to breed fish. The cost of the very first breeding is determined by the average mining power P of the parent fish and the average ecological mining power AP. The cost F=K*P/AP, tentatively K = 500. * The progeny genes are inherited from the parent fish genes, and each parent has a 50% chance to propagate its genes. * The scarcity of the fish gene is classified as normal, scarce, epic, and legendary. The scarce, epic, and legendary genes, respectively, have a 50%, 35%, and 25% chance to be inherited. There is a 1% chance to increase the gene scarcity level, or the genes will mutate into random and normal genes. **Fish Mining** - - * All fish with mining power can obtain reward tokens every day proportionately. The amount of reward token available to mine per day (M) is related to (F) the total sum of the fish (mining power>0) participating in mining. M=K*F^0.9，K as a constant, tentatively K=50. * Only the fish that are not being sold, bred, or locked by pictorial books can participate in mining. * Every time a fish participates in mining, it loses 4% of the mining power until it reaches 0. **Pictorial Book Mining** - - * A gamer can activate a pictorial book when acquiring some pure-bred fish with the built-in suites. * You can start mining reward tokens if you lock the right fish into the pictorial book. The locked fish must have full mining capacity. * There are 4 levels to each fish’s pictorial book: 0, 10, 30, and 90 growing up days in fish tanks. * When level 2, level 3 or level 4 fish are locked, the system automatically releases the low-level fish previously locked. You can only lock one fish, and you can double your points after collecting all level 4 fish, in all the colors, with the same suit. * The mined reward tokens are distributed according to the points and settled once a day. At the same time, the mining power is reduced by 4%. If the mining power is 0, then no more mining can be done. - #### Front End - - * Implement web front-end based on react.js and polkadot.js. Modules include: NFT Lottery Draw, NFT Auction Sale, NFT Minting, Fish and Fish Tank. * Implement web front-end based on react.js, polkadot.js and pixi.js. Game functions include Fishing Mining, Fish Breeding, Pictorial Book Mining. * UI mockups: https://www.figma.com/file/0uuKT3XxB6hbzyFxLnzfAr/Koi-Metaverse?node-id=0%3A1 * Fish Gene and Images: https://drive.google.com/drive/folders/1R4EoaDhoPkpxd9vchh7KLs-jx94pKad1?usp=sharing - ### Ecosystem Fit Existing GameFi NFT projects mainly focus on the public chains, games and collectible publishing, Marketplace, etc. Popular projects working in this segment include Axie Infinity (NFT game), Chiliz (sports-oriented underlying public chain), Flow (general NFT issuance public chain), and Opensea (general marketplace). We will add more game functions than Axie Infinity and build on the Substrate framework. We also can collaborate with native Polkadot NFT marketplace [RMRK](https://www.rmrk.app/) and [NFTMart](https://www.nftmart.io/). - - - # Team - ## Team Members - - * Anetta Sultygova - Project Lead * Euglena Liu - Product Manager * Yuan Li - Full-stack Developer @@ -214,43 +160,30 @@ Existing GameFi NFT projects mainly focus on the public chains, games and collec * Hongfeng Liu - Artistic Designer * Vladan Falcic - NFT Advisor - ## Team Website - - * [https://www.koi.io/](https://www.koi.io/) - ## Legal Structure - - * Koi Metaverse Ltd. is a company registered in the British Virgin Islands. - ## Team Experience Anetta Sultygova - - * 8-years project management and investing experience in the blockchain industry. She is good at structuring and organizing the teams around the projects. * Seasoned experience in NFT ecosystem and marketing strategy. * Marketing and community management in MILC, Realm, BloXmove and Metis etc. Euglena Liu - - * Product lead of fishchain and Paopaoyu (Top 10 web game on Renren “Chinese Facebook”). * 8-years gaming product design experience in the game industry. * Early player and investor in Axie Infinity ($AXS). Yuan Li - - * 10-years full stack software development experience * 5-years blockchain and smart contract development experience * Over 15 years of experiences in development and Management @@ -258,201 +191,81 @@ Yuan Li Tao Liu - - * 3-years of product management experience in the game industry. * 20-years of art design and animation experience. * Former Front-end Director of LightInBox, Fishchain and ShopperPlus. Vladan Falcic - - -* Blockchain and crypto enthusiast, he entered the crypto space back in 2014 and was mostly involved in early stage projects. -* In 2016, he started working with different projects, improving their marketing and establishing valuable partnerships. -* As the CEO of Squares Capital, he is working with several startup projects, advising them, improving their marketing and building the community. +* Blockchain and crypto enthusiast, he entered the crypto space back in 2014 and was mostly involved in early stage projects. +* In 2016, he started working with different projects, improving their marketing and establishing valuable partnerships. +* As the CEO of Squares Capital, he is working with several startup projects, advising them, improving their marketing and building the community. Jelly Ji - - * 5-years experience in html5 and front-end stack development. * Expert in mobile game development, H5 game development and blockchain game development * Bsc in Information Management and Information System of Beijing University of Posts and Telecommunications Hongfeng Liu - - * Senior UI and animation designer. * 3-years experience in blockchain game development - ## Team Code Repos - - * [https://github.com/KoiMetaverse](https://github.com/KoiMetaverse) - ## Team Linkedin Profiles - - * [https://www.linkedin.com/in/anetta-sultygova/](https://www.linkedin.com/in/anetta-sultygova/) * [https://www.linkedin.com/in/taoliu-designer/](https://www.linkedin.com/in/taoliu-designer/) * [https://www.linkedin.com/in/vladan-falcic-sqcap/](https://www.linkedin.com/in/vladan-falcic-sqcap/) * [https://www.linkedin.com/in/jelly-ji-7b193a177/](https://www.linkedin.com/in/jelly-ji-7b193a177/) * [https://www.linkedin.com/in/euglena-game/](https://www.linkedin.com/in/euglena-game/) - # Development Roadmap - ## Overview - - * Total Estimated Duration: 3 months * Full-time equivalent (FTE): 4 FTE * Total Costs: 12,000 DAI - ### **Milestone 1 —— Koi Metaverse NFT Modules and Assets** - - * Estimated Duration: 3 months * FTE: 4 FTE. * Costs: 12,000 DAI - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
          -Number - Deliverable - Specification -
          0a. - License - Apache 2.0 -
          0b. - Documentation - We will provide inline documentation, video, medium articles & start creating the lightpaper of the project. -
          0c. - Testing Guide - The code will have proper unit-test and guid coverage for Koi Metaverse modules -
          1 - smart contract: NFT Lottery Draw - NFT lottery contract include: lottery function implemented by ink -
          2 - smart contract: NFT Auction Sale - NFT auction contract include: fishList, fishGeneList, bid, refreshFishList, getMyFish functions implemented by ink -
          3. - smart contract: NFT Minting - NFT minting contract include: myNft, getNft, earned, stakeNft, withdrawNft, withdrawNftAll, getReward functions implemented by ink -
          4. - smart contract: Fish - fish contract include: gene, birthday, power, reproduction, growth implemented by ink -
          5. - smart contract: Fish Tank - fish tank contract include: capacity, totalPower, fishList implemented by ink -
          6a. - UI mock-ups - The UI design of product frontend and product workflow. -
          6b. - Fish Genes and Images - The UI design and gene system of fish NFTs. -
          7. - Front end - Implement web front-end based on react.js and polkadot.js. Modules include: NFT Lottery Draw, NFT Auction Sale, NFT Minting, Fish and Fish Tank. Fish Mining, Fish Breeding. -
          8. - Test - We will provide a dockerfile to demonstrate the usage of our modules. -
          +| Number | Deliverable | Specification | +|--------|--------------------------|-----------------------------------------------------------------------------------------------------------| +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide inline documentation, video, medium articles & start creating the lightpaper of the project. | +| 0c. | Testing Guide | The code will have proper unit-test and guid coverage for Koi Metaverse modules | +| 1 | smart contract: NFT Lottery Draw | NFT lottery contract include: lottery function implemented by ink | +| 2 | smart contract: NFT Auction Sale | NFT auction contract include: fishList, fishGeneList, bid, refreshFishList, getMyFish functions implemented by ink | +| 3. | smart contract: NFT Minting | NFT minting contract include: myNft, getNft, earned, stakeNft, withdrawNft, withdrawNftAll, getReward functions implemented by ink | +| 4. | smart contract: Fish | fish contract include: gene, birthday, power, reproduction, growth implemented by ink | +| 5. | smart contract: Fish Tank | fish tank contract include: capacity, totalPower, fishList implemented by ink | +| 6a. | UI mock-ups | The UI design of product frontend and product workflow. | +| 6b. | Fish Genes and Images | The UI design and gene system of fish NFTs. | +| 7. | Front end | Implement web front-end based on react.js and polkadot.js. Modules include: NFT Lottery Draw, NFT Auction Sale, NFT Minting, Fish and Fish Tank. Fish Mining, Fish Breeding. | +| 8. | Test | We will provide a dockerfile to demonstrate the usage of our modules. | ## Community Engagement - - * **Play to Earn:** Koi Metaverse will also adopt the P2E model to inspire players of GameFi games. Through P2E, players can share the growth and development dividend of the Koi Metaverse. * **Genesis Collection:** [Koi NFTs Genesis Collection Offering — Phase 1: Newborn](https://koimetaverse.medium.com/koi-nfts-genesis-collection-offering-phase-1-newborn-5619038200c6) Genesis Collection is an effective way to start a project and have public awareness. * **GameFi Communities:** Koi Metaverse will collaborate with game P2E communities, including Yield Guild Games (YGG), A16, etc. to complete users acquisition and users growth. - # Future Plans Our project plans to become a parachain for the Polkadot network, which provides benefits from shared security and communications (XCMP). We will launch our game application Koi Metaverse first to complete the first adoption and then open our infrastructure layer Koi Network to support more game Dapps. The Koi Network will support marketplace, NFT DeFi, GameFi Hub and Cross-chain Gateway, etc. - # Additional Information - - * Website: [https://koi.io/](https://koi.io/) (Previously [http://koi.network/](http://koi.network/)) * Twitter: [https://twitter.com/KoiMetaverse](https://twitter.com/KoiMetaverse) * Discord: [https://discord.gg/Aj5Zq9Cx9r](https://discord.gg/Aj5Zq9Cx9r) diff --git a/applications/Lastic.md b/applications/Lastic.md new file mode 100644 index 00000000000..24e097c00a4 --- /dev/null +++ b/applications/Lastic.md @@ -0,0 +1,255 @@ +# Lastic + +- **Team Name:** Lastic +- **Payment Address:** bc1q0d6pkmsvncshyeqvzzlcfjc7lkf4fuku7nsen7 (BTC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +> :exclamation: *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.* +## Project Overview :page_facing_up: + +### Overview + + - Lastic is a pioneering blockspace marketplace developed on Polkadot. + - Our mission with Lastic is to democratize Polkadot blockspace, offering cost-effective and accessible solutions. Our marketplace facilitates the purchase and sale of 'Coretime,' aiming to normalize pricing, present user-centric payment options, and possibly launch subscription or futures offerings. With Lastic, deploying or extending a Polkadot project becomes seamless. + - Our faith in the coretime model underscores Polkadot’s leadership in modular blockspace. To create a universal blockspace marketplace, we believe Polkadot’s advanced technology is unparalleled. + +### Project Details +The complete vision of Lastic is a broad and intensive endeavor that involves building on technology that is not yet complete nor wholly available. Our journey in this space reveals the risks of investing heavily in transient technologies. In alignment with the Web3 Foundation grant's objectives, our focus remains on forward-thinking strategies that offer tangible value. **Thus, our proposal emphasizes developing a user interface (UI) tailored for the Coretime Parachain.** + +This grant's goal is to create a UI within the limitations of `the broker pallet` being still in development and not deployed as a testnet yet. Concurrently, we will devise a **static mockup**, with simulated data, illustrating user interactions with the future coretime chain. + +Grant Objectives: + - Construct a UI mockup dedicated for future interactivity with the Coretime chain. + - Envision limited interactivity based on features presently available in the `broker pallet`. This is contingent on the running the pallet as a substrate node locally. + +Exclusions for this grant: + - Real-time data derived via indexers on cores acquired historically. + - Interaction beyond the limited functionality within the scope of this grant. + - Functionalities allowing Polkadot users to alter cores, such as fragmentation. + - The capability for buying or selling coretime on secondary markets, which remains Lastic's long-term vision. + +### Ecosystem Fit + +- **Role in the Ecosystem**: Lastic seamlessly integrates within the Polkadot ecosystem, offering users an intuitive interface to assess the real-time status of coretime. This includes insights into available cores, owned cores, sales prospects for coretime, task allocations, newly created regions, regions within the instantaneous coretime pool, and transactions related to instantaneous coretime. + +- **Target Audience**: Our primary user base encompasses: + - Parachain teams looking for blockspace to expand or optimize their projects. + - dApp developers aiming to ensure smooth and scalable operations. + - Smart contract developers seeking efficient blockspace management. + - Collators and validators striving for enhanced network optimization. + - Coretime providers looking for a transparent space to offer their services. + - Polkadot analysts and analytics providers in need of real-time coretime data. + - MEV actors aiming to maximize their strategies. + - DOT holders keen on understanding and optimizing their blockspace assets. + +- **Addressing the Needs**: The Lastic UI is meticulously designed to cater to users desiring a simplified yet comprehensive overview of the coretime landscape on Polkadot. In the broader vision, along with providing a better user experience for those looking to buy Bulk and Instantanious Coretime, Lastic plans to pioneer a robust secondary marketplace for Polkadot's blockspace. This platform will facilitate the buying and selling of blockspace, supporting projects that need expansion or those that have excess blockspace to offer. + +- **Comparison to Existing Solutions**: When evaluating the existing landscape within the Substrate/Polkadot/Kusama ecosystem, we found no projects that are currently in development with Lastic's vision or offerings, making our initiative unique and essential. + +## Team :busts_in_silhouette: + +### Team members + +- Phil Lucsok (aka Asynchronous Phil) +- Aurora Makovac (aka Aurora Poppyseed) + +### Contact + +- **Contact Name:** Phil Lucsok, Aurora Poppyseed +- **Contact Email:** plucsok@gmail.coml, aurora.makovac@gmail.com +- **Website:** [lastic.xyz](https://www.lastic.xyz/) + +### Legal Structure + +- **Registered Address:** Private +- **Registered Legal Entity:** In progress + +### Team's experience + +#### **Phil Lucsok**: +Phil began his career in web3 as a marketing and communications manager for a Bitcoin startup in Berlin in 2013 called [BitcoinsBerlin](https://web.archive.org/web/20220707055043/https://bitcoinsberlin.com/). There, he created marketing campaigns for multiple products including: +- [All4BTC](https://all4btc.com/) - a one-stop shop for purchasing anything on Amazon or eBay with bitcoin +- Bills4BTC (later [Bitwala](https://bitwala.com/), Nuri) - a SEPA-compliant payment method for holders of Bitcoin for regular payments +- e4BTC - an electronics shop supporting purchases in Bitcoin + +After this, he worked for 3.5 years at [ResearchGate](https://www.researchgate.net/), a web2 social media platform for scientific researchers, where he learned skills in Product Management, Product Analytics, UX development and copywriting and design, and industry-standard growth practices. + +In late 2017, Phil joined Parity Technologies to lead technical communications on Ethereum and Polkadot. There he worked closely with developers to create promotional content for open-source products including Parity Ethereum, Parity Signer, Polkadot.js. It was between 2018 and 2020 where he represented Parity in Ethereum governance to help recover the stuck funds from the November 2017 multisig hack. + +He led the communications team for the first two years, growing the team from 1 to 12, where they created and executed the launch strategies for Polkadot, Kusama and Substrate. After that he joined the Ecosystem Success team to work with parachain teams to improve their communications and act as a liason between Substrate Builders Program teams and Parity. + +Phil currently works as a freelancer but is focused on leading [Missing Link](https://www.missing-link.io/)'s marketing, communications and governance strategies. He is also an active participant in Polkadot governance discussions on the Kusamarian and in ChaosDAO. + +*Note: Phil Lucsok has not previously applied for a grant at the Web3 Foundation.* + +#### **Aurora Poppyseed**: +Aurora's journey in the technological sphere stands out for her innovative approach and unwavering determination. With a foundation in Physics and Electrical Engineering, she transitioned into roles as varied as a Solutions Architect, focusing on electronics and low-level programming, to a Frontend Developer with a commitment to clean code and scalable frontend architectures. + +At [**Instrumentation Technologies**](https://www.i-tech.si/) in Nova Gorica, Slovenia, she led the design of intuitive GUIs for advanced measurement devices in particle accelerators and streamlined future development with a standardized Vue CLI-based web GUI framework. Her contribution as a Frontend Developer at [**Block Analitica**](https://blockanalitica.com/) involved engineering the frontend framework for the [**Ajna project**](https://www.ajna.finance/) initiated by the **MakerDAO team**, ensuring clean coding practices and an organized project structure for future open-source contributions. + +Aurora attended and graduated from the [**Polkadot Blockchain Academy**](https://www.polkadot.network/development/academy/) at UC Berkeley (engineering track), learning about the fundamentals of blockchain from leaders in this domain. Further enhancing her mark in the blockchain domain, Aurora offered her expertise to [**KodaDot**](https://kodadot.xyz/), a prominent multi-chain NFT marketplace, developing developer documentation and crafting both technical and non-technical articles to amplify the platform's presence. + +In the realm of community engagement and organization, Aurora co-organized the [**Polkadot Bled mini-conference**](https://www.meetup.com/subwork/events/292274713) and more recently, orchestrated a breakfast as a side event at sub0 aimed at [**women in Polkadot** in collaboration with **H.E.R. Dao**](https://lu.ma/dzuqx5nw). This gathering aimed to empower and bring together women leaders and enthusiasts in the Polkadot ecosystem. Furthermore, she's a staunch supporter of [**SubWork**](https://subwork.xyz/), a tech-centric coworking hub in the scenic Bled region and one of the pioneer **Polkadot hubs**. + +Now a freelance blockchain developer, Aurora champions women's representation in Polkadot and ardently supports community-driven blockchain initiatives. + +*Note: Aurora Poppyseed has not previously applied for a grant at the Web3 Foundation.* + +--- + +### Team's Repository & Online Presence + +**Organization's GitHub Page**: +- [LasticXYZ Official Page](https://github.com/LasticXYZ) + +**Primary Repository for Grant Submission**: +- [Lastic UI Repository](https://github.com/LasticXYZ/lasticUI) + +**Team Member GitHub Profiles**: +- [Phillux's GitHub](https://github.com/phillux) +- [PoppyseedDev's GitHub](https://github.com/poppyseedDev) + +**LinkedIn Profiles**: +- [Philip Lucsok](https://www.linkedin.com/in/philiplucsok) +- [Aurora Makovac](https://www.linkedin.com/in/auroramakovac) + +## Development Status & Progress + +The main hub of our grant-related development is the [LasticUI Repository](https://github.com/LasticXYZ/LasticUI). The groundwork of this repository stems from the [substrate frontend template](https://github.com/substrate-developer-hub/substrate-front-end-template), providing us with a robust starter code. + +We're progressing by configuring our frontend development environment locally, leveraging the Substrate framework, and establishing a direct connection with it. Detailed setup and operational instructions can be accessed in the repository's [README.md](https://github.com/LasticXYZ/LasticUI/blob/main/README.md). + +Our secondary [Lastic Repository](https://github.com/LasticXYZ/Lastic) is currently private but will soon transition to public access. This space captures our internal deliberations framed as issues, preliminary whitepaper drafts, and an essential frontend for our main website, [lastic.xyz](https://www.lastic.xyz/), augmented with pertinent links. + +**Insightful Blogs**: +1. [The Genesis of a Coretime Marketplace for Polkadot](https://medium.com/lastic-marketplace/the-genesis-of-lastic-a-coretime-marketplace-for-polkadot-9dc851fa365f) +2. [Polkadot 2.0 - A new era of decentralization](https://medium.com/lastic-marketplace/polkadot-2-0-a-new-era-of-decentralization-d5626a6e63e5) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Total Costs:** 10000 USD + +### Milestone 1 - Creating a Frontend with basic functionality for the coretime chain + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 10000 USD + +> :exclamation: **The default deliverables 0a-0d below are mandatory for all milestones**, and deliverable 0e at least for the last one. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Licensed under GPLv3 | +| **0b.** | Documentation | Comprehensive documentation will include inline code comments and a detailed wiki. The wiki will clarify core terms such as “coretime” and “assignments” for user understanding. This will be a one-stop resource for insights into coretime's intricacies and functionalities. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive UI testing framework to ensure functionality and robustness. UI Testing involves making sure all functionality works as intended, and from different browsers, OSs and platforms. On MacOS, Linux, and Windows, we will test browsers including, but not limited to: Chrome, Firefox, Safari, Edge, Brave and Safari for iOS and Chrome on Android. We will test for consistency across platforms and browsers, ensuring all navigational elements work, all graphics are rendered correctly, all data is updated in a timely fashion, for mobile responsiveness, and that there are no unintended results. | +| **0d.** | Error logging | In the event of an error, we will ensure the UI writes the error details to an event viewer or log file for later review. | +| **0e.** | Article Publishing | **Five articles** will be published covering topics from Polkadot 2.0 insights to the Lastic long-term vision. 1. [The Genesis of a Coretime Marketplace for Polkadot](https://medium.com/lastic-marketplace/the-genesis-of-lastic-a-coretime-marketplace-for-polkadot-9dc851fa365f) 2. [Polkadot 2.0 - A new era of decentralization](https://medium.com/lastic-marketplace/polkadot-2-0-a-new-era-of-decentralization-d5626a6e63e5) 3) How Agile Coretime works and what it provides 4.) Further Coretime developments based on Gavin's talk at Protocol Berg (Corejam, Coreplay) 5. The Lastic Roadmap, including our future long-term vision of Lastic | +| 1. | Whitepaper creation | Comprehensive Lastic whitepaper creation. | +| 2a. | User Flow Diagram Design | A user-centric flow diagram will be designed to showcase the interaction journey on the platform. This design will be in line with the principles highlighted in the RFC for coretime chain and broker pallet. It will primarily cover the instantaneous coretime sales and primary market sales, leaving out the secondary market. The finalized user flow diagram will be accessible via a link in the LasticUI repository's README.md file. | +| 2b. | UI Figma Design | We will craft a Figma-based UI design for the coretime chain, with the focus on instantaneous coretime sales and primary market sales (excluding the secondary market). This task will be undertaken without the aid of a professional designer. Preliminary mockups for this stage have been initiated and further details can be gleaned from the expansion of section 3.b. The complete design will be shared through a link in the LasticUI repository's README.md file. | +| 3a. | Frontend Development - Broker Pallet Integration | This phase will integrate basic interactions available in the `broker pallet` into the frontend. Detailed insights into the interactable features can be found in the expanded section of 3.a. Key deliverables will encompass the inclusion of all listed UI extrinsic functions, relevant UI constants, and selected UI storage queries limited to the fuctionality that can be implemented locally. More details are available in the expansion of 3.a section. | +| 3b. | Mockup-based Frontend Development | We will bring to life the mockups for both Instantaneous Coretime sales and the primary market for Bulk Coretime sales as visualized in the UI designs under section 2.b. These mockups will due to limitations of time restirictions only feature "fake data" and not the actual data from the coretime chain. To get an in-depth view of these, refer to the expanded details in section 3.b. | + +--- + +### Expansion of 3.a - Basic Interaction Creation + +#### UI extrinsic functions: + +*Note: Functions with system admin privilege are not included here and will not be included in the UI.* + +| Function Name | Description | +|---------------|-------------| +| renew | Renew Bulk Coretime in the ongoing Sale or its prior Interlude Period. | +| transfer | Transfer a Bulk Coretime Region to a new owner. | +| partition | Split a Bulk Coretime Region into two non-overlapping Regions at a particular time into the region. | +| interlace | Split a Bulk Coretime Region into two wholly-overlapping Regions with complementary interlace masks which together make up the original Region's interlace mask. | +| assign | Assign a Bulk Coretime Region to a task. | +| pool | Place a Bulk Coretime Region into the Instantaneous Coretime Pool. | +| claim_revenue | Claim the revenue owed from inclusion in the Instantaneous Coretime Pool. | +| purchase_credit | Purchase credit for use in the Instantaneous Coretime Pool. | +| drop_region | Drop an expired Region from the chain. | +| drop_contribution | Drop an expired Instantaneous Pool Contribution record from the chain. | +| drop_history | Drop an expired Instantaneous Pool History record from the chain. | +| drop_renewal | Drop an expired Allowed Renewal record from the chain. | +| request_core_count | Request a change to the number of cores available for scheduling work. | + +#### UI constants: + +| Constant Name | Description | +|---------------|-------------| +| PalletId | Identifier from which the internal Pot is generated. | +| TimeslicePeriod | Number of Relay-chain blocks per timeslice. | +| MaxLeasedCores | Maximum number of legacy leases. | +| MaxReservedCores | Maximum number of system cores. | + +#### UI storage to query: +_Note: Not all storage to query listed here will be implented in the scope of this grant._ + +| Storage Item | Description | +|--------------|-------------| +| Configuration | The current configuration of this pallet. | +| Reservations | The Polkadot Core reservations (generally tasked with the maintenance of System Chains). | +| Leases | The Polkadot Core legacy leases. | +| Status | The current status of miscellaneous subsystems of this pallet. | +| SaleInfo | The details of the current sale, including its properties and status. | +| AllowedRenewals | Records of allowed renewals. | +| Regions | The current (unassigned) Regions. | +| Workplan | The work we plan on having each core do at a particular time in the future. | +| Workload | The current workload of each core. This gets updated with workplan as timeslices pass. | +| InstaPoolContribution | Record of a single contribution to the Instantaneous Coretime Pool. | +| InstaPoolIo | Record of Coretime entering or leaving the Instantaneous Coretime Pool. | +| InstaPoolHistory | InstaPool rewards for each Timeslice and the number of core parts which contributed. | + + +### Expansion of 3.b - Basic Interaction Creation +_Note: All designs featured here are just quick design mockups and will be prone to change during the duration of this grant._ + +This mockup/UI design features the design of the page Instantanious Coretime sales. +![Instantanious coretime sales](https://github.com/LasticXYZ/Grants-Program/assets/30662672/f8ecbca8-1b8a-4214-a0a0-5281e880c4de) + +This mockup/UI design features the design of the page primary market for the Bulk sales. +![Primary market bulk sales](https://github.com/LasticXYZ/Grants-Program/assets/30662672/d1b65609-c763-449d-bdba-e2c92f0387ec) + +**** We will create a frontend allowing users to see the current state of Coretime on Polkadot, including, but not limited to: Number of cores available, Number of cores assigned, Number of legacy cores assigned, Number of blocks in the Instantaneous Pool, Number of Cores parititioned, etc. Note: this will be made using dummy data. | + + +## Future Plans + +- Lastic aims to become a secondary marketplace for blockspace on Polkadot using its new Agile Coretime model +- We intend to first build out a UI for the community to gather, assess, and analyze the state of Coretime including its availability and sales +- After Agile Coretime is enabled on Rococo, we will plug in our UI so that it can become useful to the community right away +- Lastic will support Rococo, Kusama and Polkadot +- Users will be able to purchase coretime in the 'default' methods of bulk and instantaneous via Lastic +- Users will be able to use Lastic as a way to view, paritition, resell, purchase, and trade coretime in various ways +- The long-term vision for Lastic is that it will be the one place for ANY user to buy and sell blockspace on Polkadot, regardless of the state machine or smart contract or application they have. +- Lastic aims to support features for the upcoming roadmap laid out in the RFCs, for example Coreplay and Corejam + +### On the Horizon: Frontend Development with Blockchain Integration: + +Initiation Timeline: Post the release of W3F's branch on the Rococo testnet, followed by data availability for real-time functionality testing. Estimated commencement: 4 months post-Rococo testnet launch, with the mainnet integration slated 3-6 months thereafter. + +Developmental Milestones: + + - Integration with Subquery to facilitate efficient storage querying. + - Design and implement a dynamic pricing simulation tool. + - Facilitate smooth synchronization with testnet, subsequently followed by devnet. + - Establish a robust secondary marketplace, ensuring it undergoes rigorous testing phases. + - Pave the way for feature enablement on major platforms such as Polkadot and Kusama's mainnets. + - Dedicated efforts towards crafting a user-centric interface for the secondary marketplace. For a preliminary glimpse of our vision, refer to the mockup showcased below: +![Secondary market bulk sales](https://github.com/LasticXYZ/Grants-Program/assets/30662672/19b1cff8-ac16-4cea-81e5-385a29ee46f6) + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +- Phil's experience working at Parity informed him of the Web3 Grants program. +- Aurora has learned about the Web3 Grants program during her time working at KodaDot. + +Additional information: +- We have received no financial contributions to Lastic, nor have applied for any other grants diff --git a/applications/Libra.md b/applications/Libra.md index c61d21c6193..2e6bb1c327f 100644 --- a/applications/Libra.md +++ b/applications/Libra.md @@ -1,6 +1,5 @@ -# Project Libra +# Libra - Decentralized Payment Network -- **Project Name:** Libra - Decentralized Payment Network - **Team Name:** @Scale Technologies - **Payment Address:** 0x77AE9e7c90E6f6137AC3b3cd09A4bdc4654A0fe5 (ERC20 USDT) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 @@ -26,6 +25,7 @@ Resolvers Network leverages the power of blockchain and the community to resolve Libra bridges the gap between blockchain and eCommerce to enable all people to exchange value and transact globally, securely, at significantly lower cost, and more inclusively than traditional financial systems allow. ### Project Details + The project's scope is to build three core components that define the foundation of Libra Network: LRP protocol, Resolver Networks, and Javascript SDK. From these components, people can easily integrate the cryptocurrencies payment to their business while their customers are protected by Libra Network. #### LRP protocol @@ -34,10 +34,10 @@ LRP protocol allows buyer and seller to make a p2p payment while the cryptocurre ![Project Libra-LRP Protocol](https://user-images.githubusercontent.com/92568442/148349639-145690aa-98c3-4e13-b9a3-ccfa01d55f6a.png) - For the LRP protocol, the data model for LRP protocol should be generic and flexible for any use cases. Besides, it should be small to store on-chain but need to provide enough information if needed (e.g. dispute case). ##### Data model + ```json { "id": "uuid", @@ -52,6 +52,7 @@ For the LRP protocol, the data model for LRP protocol should be generic and flex "updated_at": 1640761504444 } ``` + ##### State transition ![state-transition](https://user-images.githubusercontent.com/92568442/148345661-fd24292a-389b-44ef-95a5-5d8422f546c6.png) @@ -69,9 +70,11 @@ This diagram shows the whole dispute process ![Project Libra- Dispute process](https://user-images.githubusercontent.com/92568442/148343813-2f581a72-36b7-4065-bf69-cb0d642f25f5.png) #### SDK + The SDK is indispensable for the product’s adoption. It should be developer-friendly and easy to integrate with a few lines of the code. The interface of the SDK is listed below. **Install** + ```bash npm install libra-sdk ``` @@ -81,17 +84,18 @@ import Libra from "@libra-sdk"; const libra = new Libra(config); ``` + **Checkout** Create a payment with the SDK ```jsx const payment = libra.createPayment({ - payee, - amount, - currency, - description, - receipt + payee, + amount, + currency, + description, + receipt }); ``` @@ -101,22 +105,23 @@ Cancel a payment (before the seller accept) libra.cancelPayment(payment.id) ``` -Complete a payment +Complete a payment ```jsx libra.complePayment(payment.id); ``` -Dispute a payment +Dispute a payment ```jsx libra.dispute({ - paymentId: payment.id, - evidence: {...} + paymentId: payment.id, + evidence: {...} }); libra.escalateDispute(disputeId); ``` + **Seller’s dashboard** Get payments @@ -153,11 +158,11 @@ Setup identity ```jsx libra.setIdentity({ - displayName, - legalName, - email, - website, - ... + displayName, + legalName, + email, + website, + ... }); ``` @@ -165,9 +170,9 @@ Apply resolver ```bash libra.apply({ - role: "resolver", - application: {...}, - deposit: 100000, + role: "resolver", + application: {...}, + deposit: 100000, }); ``` @@ -175,9 +180,9 @@ Nominate ```jsx libra.nominate({ - address, - amount, - ... + address, + amount, + ... }); ``` @@ -199,11 +204,11 @@ libra.rejectAppeal(disputeId); ### Ecosystem Fit -- **Where and how does your project fit into the ecosystem?** Libra is built on top of Substrate. Thanks to Substrate's ecosystem, Libra supports all substrate tokens as a payment method by default. +- **Where and how does your project fit into the ecosystem?** Libra is built on top of Substrate. Thanks to Substrate's ecosystem, Libra supports all substrate tokens as a payment method by default. - **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** Libra's target audience is sellers/buyers who want a safer, faster, more straightforward solution for online payment using cryptocurrencies. Through Resolvers Network, Libra also brings new jobs and a new way to earn income by solving disputes. -- **What need(s) does your project meet?** Libra provides a safe mechanism for both buyers and sellers to transact online -- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** As far as we know, Libra, with its unique LRP protocol and Resolvers network, is the first project designed to solve real-world eCommerce transactions. There are no similar projects in the ecosystem yet. +- **What need(s) does your project meet?** Libra provides a safe mechanism for both buyers and sellers to transact online +- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** As far as we know, Libra, with its unique LRP protocol and Resolvers network, is the first project designed to solve real-world eCommerce transactions. There are no similar projects in the ecosystem yet. ## Team :busts_in_silhouette: @@ -219,33 +224,36 @@ Libra's target audience is sellers/buyers who want a safer, faster, more straigh - **Website:** https://atscale.xyz ### Legal Structure + (We're in the process of registering the legal entity) + - **Registered Address:** N/A - **Registered Legal Entity:** N/A ### Team's experience -AtScale is a team specialized in blockchain development. We aim to rely on blockchain technologies to solve real-world problems and facilitate blockchain-based products to mass adoption. +AtScale is a team specialized in blockchain development. We aim to rely on blockchain technologies to solve real-world problems and facilitate blockchain-based products to mass adoption. -- **Anthony Dong**: Anthony successfully built and exited several internet startups during the last ten years. Anthony was the CTO in his recent company, helping the company bootstrapped from zero to $15 million ARR (Annual Recurring Revenue) in 2 years. +- **Anthony Dong**: Anthony successfully built and exited several internet startups during the last ten years. Anthony was the CTO in his recent company, helping the company bootstrapped from zero to $15 million ARR (Annual Recurring Revenue) in 2 years. - **Andrew Le**: Andrew was the Lead Researcher at his previous company, specializing in AI/Machine Learning and Blockchain technologies. He led the development to build one of the most accurate body measurement prediction engines in the industry during his past job. ### Team Code Repos -- https://github.com/atscaletech/ -- https://github.com/atscaletech/polkadot-hackathon-apac +- https://github.com/atscaletech/ (AtScale Technologies) +- https://github.com/atscaletech/polkadot-hackathon-apac (Hackathon Submission) ### Team LinkedIn Profiles (if available) Due to privacy concerns, the team information will provide in private by email if requested. ## Development Status :open_book: + Libra is founded and developed in the Polkadot APAC Hackathon 2021. We already built a proof of concept application and here is our hackathon submission: - Pitch video: https://youtu.be/pR4_2nrrJQQ - Demo screencast: https://youtu.be/cR7gKSzVoAY - Live demo: https://app.libra.atscale.xyz -- Explorer: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.libra.atscale.xyz#/explorer +- Explorer: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frpc.libra.atscale.xyz#/explorer - Git repository: https://github.com/atscaletech/polkadot-hackathon-apac ## Development Roadmap :nut_and_bolt: @@ -255,7 +263,7 @@ Libra is founded and developed in the Polkadot APAC Hackathon 2021. We already b - **Total Estimated Duration:** ~ 4 months - **Full-Time Equivalent (FTE):** 1.5 FTE - **Total Costs:** 16,000 USD - + ### Milestone 1 - LRP Protocol Implementation - **Estimated duration:** 1 month @@ -269,7 +277,7 @@ Libra is founded and developed in the Polkadot APAC Hackathon 2021. We already b | 0c. | Testing | All of the code will be covered by unit and integration test suites with the testing instruction. | | 0d. | Live testnet | The live testnet with a few nodes and public RPC endpoints to test or connect more nodes. | | 1. | Substrate module: LRP pallet | The LRP protocol implementation. | -| 2. | Substrate module: Currencies pallet | The extended module of ORML currencies allows creates and manages currencies by bonding some native tokens. | +| 2. | Substrate module: Currencies pallet | The extended module of ORML currencies allows creates and manages currencies by bonding some native tokens. | | 3. | Substrate based chain | The integration LRP protocol with substrate chain. | ### Milestone 2 - Resolvers Network Implementation @@ -314,12 +322,12 @@ In the short term, we plan to launch the validation and testing phase: - **Canary network launch:** At the end of this phase, we plan to join the Kusama para-chain auction and launch the canary network. For the long term plan, we will: + - Launch Polkadot para-chain - Acquire more users and boost the network's GMV (gross merchandise value) - Scale up the resolvers networks - Develop tools for Libra such as fraud payment detection, API, AI/ML dispute processor, ... - ## Additional Information :heavy_plus_sign: **How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/LightSpell-proposal.md b/applications/LightSpell-proposal.md new file mode 100644 index 00000000000..d4a4a3194ca --- /dev/null +++ b/applications/LightSpell-proposal.md @@ -0,0 +1,271 @@ +# LightSpell XCM API by ParaSpell✨ + +- **Team Name:** ParaSpell✨ +- **Payment Address:** 0xB7d45Ef044fD9342e4c03e28D9e9bddA2d4Fe3e1 (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 🐣 + + +## 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) + +What is ParaSpell: +ParaSpell is an XCM & XCMP Developer tool 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 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) + +The following extrinsic can be subscribed into and we can check for its events on the front end. ParaSpell provides the front end for testing XCM transactions and XCM called [UI-V2](https://github.com/paraspell/ui-v2). This UI is also deployed on Netlify so users only have to run the local network to start testing. UI also provides the ability to open or close HRMP channels or test out XYK pool functionality that was implemented in collaboration with the HydraDX team. In the picture below we provide an overview of the UI. +Screenshot 2023-02-15 at 10 36 01 + + +### Overview 🎨 + +ParaSpell is split into three main repositories at the moment and one new is being added soon: + +- XCM API - TBA: Meant to provide much faster response than integrating XCM SDK as well as being easier to integrate than XCM-SDK (No install needed) +- [XCM SDK](https://github.com/paraspell/xcm-sdk): Meant to unify cross-chain experience on Substrate. Can serve any dApp developer that wishes to integrate XCM or other pallets support for they app. +- [UI-V2](https://github.com/paraspell/ui-v2): Allows for launching local network and testing XCM or HRMP channels across that local network +- [Docs](https://github.com/paraspell/docs): Extensive documentary for overview of ParaSpell, guide for SDK and UI + + + +#### SDK +This SDK currently support 46 compatible XCM nodes. They can transfer XCM messages in three different scenarios. +- Parachain to Parachain - HRMP +- Parachain to Relay chain - UMP +- Relay chain to Parachain - DMP + +SDK contains many useful features that allow for easier inntegration: +- Builder pattern implementation, easy to construct XCM calls, much more used recently for simplicity of implementation. + +- Suggestions, SDK contains TYPES that help to guide developer through integration. For example he get's compatible nodes suggested. +![1_59xApnboumYhzuRHKx60TA](https://user-images.githubusercontent.com/55763425/219314223-79c31085-2e90-4dc7-ad51-da96de730ea0.png) + +- Console printouts, SDK allows for printing into console so developer can alway check if 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.. + +#### UI-V2 +UI is used as testing tool for Parachain developers, they can simply add their node into network and test it with HRMP channels as well as XCM transfers. UI also allows dApp developers to test and learn XCM before integrating it from our SDK. + +UI is made to be as simple to use as possible. It is now also deployed on netlify so developers only have to start local network from configuration file provided by ParaSpell which starts network of Relay chain and 3 different Parachains (Bifrost,Karura & Pichiu) + +Below are some examples of UI with running network: +Screenshot 2023-02-16 at 13 31 06 + +Above we can see open/ close channel screen. It is simple to work with and intuitive. Nodes are pulled from relay chain by query so if network is not running you cannot see any nodes. + +Screenshot 2023-02-16 at 13 31 20 + +Above we can observe, that UI contains simple Wallet login with test accounts. + +Screenshot 2023-02-16 at 13 31 33 + +Above we can see XCM screen which is also very simple to navigate and nodes are pulled from relay chain by query. + +#### Docs +Docs contain important information regarding SDK, UI and other repositories that are in ParaSpell or ParaSpell contributed to / collaborated with. +The key areas are: +- Introduction +Screenshot 2023-02-16 at 13 44 58 +- Guide on importing SDK +Screenshot 2023-02-16 at 13 45 09 + +- Guide on launching local network and UI +Screenshot 2023-02-16 at 13 48 43 + + +- Guide on executing operations in UI +Screenshot 2023-02-16 at 13 45 24 + +- Guide on implementing SDK +Screenshot 2023-02-16 at 13 46 01 + + +- Important links +Screenshot 2023-02-16 at 13 45 30 + +#### Architecture 🏗️ +##### Old +The old design had SDK integrated into dApp: + +![taskFlow](https://user-images.githubusercontent.com/55763425/198412240-e031d877-c5d8-4952-9048-2e1256ba4469.svg) + +UI is purposely designed to be as simple as possible. This guarantees, that all tasks can be done quickly and without extended searching. All necessary screens also feature notifications which will as a milestone explain be callback reactive. The loading screen is only present on the first application & network startup, once accessing the same screen after the application was loaded it will be skipped automatically. The screen serves to register necessary assets in parachain nodes. This is only required to be run once per network startup. + +SDK currently handles transfers to 46 compatible Parachains and also can transfer to both Relay chains. + +##### New +In the new 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. +![taskFlowNew](https://user-images.githubusercontent.com/55763425/247828546-b16e1a8b-c16d-462b-856a-2546fa1dee00.png) + +#### Technology Stack 💻️ +- Vue.js +- Node.js +- Typescript +- Polkadot api libraries +- Make +- Parachain launch +- Substrate compatible nodes (For now Rococo, Pichiu(Kylin network), Bifrost & Acala) +- Nest.js + +### Ecosystem Fit 🌳 + +#### 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 will enable 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. + +#### XCM SDK + +There are not many XCM & XCMP-related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster. + +In Polkadot and Kusama ecosystems, there are few XCM-related tools in development. For example, Moonbeam XCM SDK was released only recently. We bring a comparison table that compares our ParaSpell SDK to Moonbeam SDK +| Features | ParaSpell XCM SDK | Moonbeam XCM SDK | +| -----: | ----------- | ------------- | +| Number of packages user has to install | User needs to install only 1 package | User needs to install 2 packages | +| Support for Parachains | Already integrated for every XCM compatible pallet | Every new node has to be added manually by user | +| Build pattern | Integrated as intuitive as possible | Integrated, not as intuitive to implement however | +| Support for asset pallet operations | Integrated | Not integrated | +| Support for HRMP pallet operations | Integrated users can open & close HRMP channels on their local chain (Useful feature for devs) | 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 | +| Support for Axelar GMP (General message passing) that will connect Substrate with EVM chains | Planned to be implemented in the future | No data | + + + +Unlike the already mentioned "Moonbeam XCM" platform ParaSpell provides UI enhancement that uses our XCM SDK and users can try/learn technology from it. ParaSpell also includes support for 46 Substrate Parachains that have XCM pallets compared to Moonbeam XCM to which users have to implement compatible nodes manually. ParaSpell SDK only needs one package compared to Moonbeam XCM which has a total of two. Compared to Moonbeam XCM which contains only XCM calls ParaSpell also contains calls that can open or close HRMP channels. We also include support for Parachains that have a template pallet for XCM called polkadotXCM this pallet is a little harder to work with than xTokens, even more for inexperienced developers. On top of that, this proposal aims to improve ParaSpell even further with introduction of LightSpell XCM API. We have not yet seen any XCM-API proposals or project and we aim to solve this gap as first team. + +Another comparison worth mentioning is UI vs Morph which is also an enhancement of the XCM UI Transfer tool +| Features | ParaSpell XCM UI | Morph | +| -----: | ----------- | ------------- | +| Focus: | Developers & users that wish to try XCM locally first | Users | +| Wiki: | Comprehensive Wiki explaining XCM, how to add assets to UI & Nodes and more implemented | Not implemented | +| Support for transfers: | In three different scenarios | In two scenarios | +| Support for local network configuration: | Fully implemented example network configuration that uses maintained Parachain-launch library | Not implemented | +| Support for HRMP channel opening/closing: | Fully implemented | Not implemented | + +Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains. + +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, this improves even further. + +Our target audiences are Web3 projects and starting/current blockchain developers. +## 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, Slovak Republic +- **Registered Legal Entity:** Dušan 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 XCMP & ParaSpell project. It is published by IEEE [link](https://ieeexplore.ieee.org/document/9872938). He also successfully presented it at ICBC 2023 conference held in Dubai. Dušan also 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 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 NFT that was minted as a certificate by Parity - [link](https://singular.app/collectibles/statemine/20/12) + + +- 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 with Dušan and he delivered many of the key features SDK now offers. + +### Team Code Repos + +- https://github.com/paraspell/xcm-api +- https://github.com/paraspell/xcm-sdk +- https://github.com/paraspell/ui-v2 +- 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: + +The new [XCM-API](https://github.com/paraspell/xcm-api) is in development and we are currently searching for the fastest server with the lowest cost requirements. + +[SDK](https://github.com/paraspell/xcm-sdk) is currently released into the main and is in a version that is fully operable. There are still some tweaks we plan to add and make, they are not part of this grant however. [UI-V2](https://github.com/paraspell/ui-v2) currently runs on state-of-the-art technology version VueJS 3 and the newest version of Nuxt. It deprecated V1 and introduced a much smoother interface and modules brought from the sub-scaffold template ParaSpell contributed to. [Docs](https://github.com/paraspell/docs) are currently in ready state but there is still some tweaking to do. + +**Sidenote**: We have recently developed an article about Polkadot & Paraspell called Enhancing XCMP Interoperability Across Polkadot Paraverse and it was accepted to the International IEEE BCCA 2023 conference held in Kuwait. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 10 000 USD + +### Milestone 1 - Create LightSpell⚡️: XCM-API + +- **Estimated duration:** 2 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 & core unit tests will be provided | +| 0e. | Create Medium article about development of LightSpell | Add article covering new features & improvements brought with LightSpell | +| 1.a | Integrate API for XCM functionality | Use Nest.js to integrate core XCM SDK functionality to send XCM messages | +| 1.b | Integrate API for Asset functionality | Use Nest.js to integrate core XCM SDK functionality to do Asset operations | +| 1.c | Integrate API for XCM Pallets functionality | Use Nest.js to integrate core XCM SDK functionality to query XCM Pallets of different Parachains | +| 1.d | Integrate API for HRMP functionality | Use Nest.js to integrate core XCM SDK functionality to open/close HRMP channels | +| 2. | Integrate token authentification | Integrate token authentification with limited requests to remove the possibility of DDOS (Bigger request limit can be requested for free via email provided in docs)| +| 3.a | Add core Integration tests | Add core Integration tests to ensure everything is working together as expected | +| 3.b | Add core Endpoint (e2e) tests | Add core endpoint tests to let the user try to use API without writing any code and also to demonstrate if API works | +| 4. | Integrate LightSpell into ParaSpell docs | Add comprehensive guide for every feature that API will offer [link](https://paraspell.github.io/docs/api/TBA.html) | + +## Future Plans 🔭 + +Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels. + +The project goal is that XCM-SDK & XCM-API will serve dApp developers and UI will teach new substrate developers to use XCM and will serve existing substrate developers to test their freshly baked Parachains. + +The newly added XCM-API will simplify XCM-SDK integration and will be much faster than integrating XCM-SDK into dAPP directly. Both repositories will remain dependent on each other. Further maintenance funding for servers and keeping XCM API up to date will be requested from Polkadot treasury. + +## 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 [links TBA] +- 💼 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] diff --git a/applications/LiisaPortfolioTracker.md b/applications/LiisaPortfolioTracker.md new file mode 100644 index 00000000000..669e4c37c28 --- /dev/null +++ b/applications/LiisaPortfolioTracker.md @@ -0,0 +1,280 @@ +# Polkadot NFT Portfolio Tracker by Liisa - MVP + +- **Team Name:** Liisa +- **Payment Address:** Fiat 04.01.2024, 11:55 PM GMT +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + + +## Project Overview :page_facing_up: + +Liisa operates as a multi-chain NFT data analytics platform, engineered to empower collectors and investors in making proficient, data-driven decisions. + +This project consists of the development of a custom-built portfolio tracker, explicitly devised for NFTs within the Polkadot blockchain network, catering to the specificities of NFT investment strategies. + +Within the Substrate/Kusama/Polkadot/Web 3 ecosystem, Liisa intends to emerge as a central supplier of granular NFT analytics, distinguishing itself with a user interface tailored to meet the specific requirements of NFT investors. + +The portfolio tracker is designed to accommodate the diverse needs of a broad user base, ranging from active traders to long-term investors and collectors. It pioneers innovative metrics that drive the NFT infrastructure forward, thereby promoting a robust and data-enriched investment environment. + + + + +### Architecture + +![Architecture New](https://github.com/LiisaNFT/W3F-Grants-Program/assets/139144686/5ded60b3-0409-44fb-a619-b47c0c6e7de7) + + +### Technologies + +#### 1) Node.js + +Node.js is an open-source, cross-platform, back-end JavaScript runtime environment that runs on the V8 engine and executes JavaScript code outside a web browser. It allows developers to use JavaScript to write command line tools and for server-side scripting, enabling the development of fast and scalable network applications. Node.js is event-driven and non-blocking, which makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. + +Within the context of the project, the following packages are used: + - Axios: Axios is an npm package for making HTTP requests in Node.js, simplifying API calls. + - pg: The "pg" package connects Node.js applications to PostgreSQL databases, enabling efficient data retrieval and manipulation. + - Polkadot.js: Polkadot.js simplifies connecting and interacting with the Polkadot ecosystem + - Squid SDK: Squid SDK is a set of tools and libraries to efficiently query the Archive data, transform, enrich and persist into the target store. Squid SDK projects are called squids. + +#### 2) Bubble.io + +Bubble.io is a visual development platform designed to democratize the process of creating web applications. It enables users, even without traditional coding skills, to build complex web applications through a user-friendly interface. Its features include visual programming capabilities, database management tools, a design editor, API integration, and hosting solutions. Essentially, Bubble.io is part of the no-code movement, which allows rapid digital product creation and innovation without requiring deep technical expertise. + +#### 3) React.js + +React.js, often simply called React, is an open-source JavaScript library developed by Facebook for building user interfaces. It allows developers to create reusable UI components and manage the state of an application efficiently. React operates on a virtual DOM, which optimizes rendering by minimizing direct manipulation of the actual DOM and by batching multiple changes together. This results in improved performance and a more seamless user experience. React's component-based architecture and its emphasis on declarative programming make it easier to understand, maintain, and scale applications. + +### Components + +#### 1) Data Source (Subsquid) + +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) 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), 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. + +All the code for data enrichment will be opensource so that more developers in the ecosystem can leverage our processes for retrieving NFT data from Subsquid API and wallets, as well as creating NFT metrics. + +#### 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 Google Cloud Platform (GCP). + +#### 4) Frontend + +We've chosen React.js for our frontend development, due to its open-source nature, and also with the intention of open-sourcing our own platform. This aligns with our commitment to enriching the Polkadot ecosystem, enabling more developers to leverage, adapt, and expand upon our work. React's component-driven approach ensures efficient and modular development, especially vital for our analytics platform. This decision guarantees adaptability for our MVP phase and scalability for expansive growth + +#### 5) Bubble.io plug-ins + +While our frontend for the Portfolio Tracker MVP will be developed using React.js, we recognize the importance of our broader platform's integration with Bubble.io. Hence, we will develop open-source plug-ins for Bubble.io, enabling connections to the selected wallets: Subwallet, Parity signer, Polkadot-js, Fearless wallet, Nova Wallet, and Talisman. These plug-ins, built using Node.js, will empower users to log in using their wallets and facilitate retrieving NFT ownership data for portfolio metrics computation. By open-sourcing these plug-ins, we aim to enhance the no-code community's access to the Polkadot ecosystem. Regarding the integration of React with Bubble.io plugins: While React itself doesn't natively support Bubble.io plugins, we can create a bridge using APIs or webhooks. + +### Ecosystem Fit + +Upon delving deeper into the NFT portfolio tracking landscape within the Polkadot ecosystem, it's evident that while some platforms have incorporated NFT capabilities, they largely remain as extensions of their primary token and DeFi services. Our solution, on the other hand, is purpose-built for NFTs, offering a dedicated platform tailored for the nuanced requirements of NFT enthusiasts and investors. + +As we look ahead, we're keen on forging strategic collaborations with NFT-centric parachains, such as Unique Network, and various NFT marketplaces. Such partnerships will not only amplify the Liisa portfolio tracker's functionality—through the integration of off-chain data—but also bolster their services by synergizing with our advanced analytical tools. + +#### Similar projects: +- Nansen Portfolio +- De.Fi +- Coinstats + +#### What makes us different is: +While platforms like Nansen and Coinstats have made significant strides in the broader crypto space, their focus is primarily on tokens, leaving Polkadot NFTs out of their purview. Meanwhile, the De.Fi platform's emphasis in this domain is still emerging. This observation underscores a distinctive opportunity in the Polkadot ecosystem: the need for a specialized NFT portfolio tracker, a niche we are poised to occupy. + +In the absence of direct parallels, our differentiation can be better understood when juxtaposed with existing wallet services from a technical perspective. + +Technical Differentiation: +1) Users receive an all-encompassing summary, highlighted by our unique Portfolio Scorecard, which evaluates liquidity, volatility, and NFT diversification. +2) Our platform goes beyond static visuals, offering dynamic filtering and sorting capabilities based on salient metrics such as sales and estimated value, resulting in a blend of technical robustness and user engagement. +3) Every NFT token is accompanied by a wealth of insights, ranging from its rarity rank within a collection to a meticulous activity log detailing all related transactions. +4) An aggregated perspective on NFT assets per collection is provided, supplemented with intuitive search features and dynamic filtering, presenting users with an innovative lens to evaluate collection performance. + +In essence, our initiative pioneers novel metrics, visualization techniques, and deep dives into the NFT realm, setting a precedent in the Polkadot ecosystem. + +## Team :busts_in_silhouette: + +### Team members + +- Bernardo Silva: Team Leader, Co-Founder & CEO at Liisa +- Paulo Peixoto: Lead Developer, Full-stack developer, Co-Founder & CTO at Liisa +- Kerim Caner Tümkaya: Backend developer, Data Engineer at Liisa +- Guilherme Leitão: Backend developer, Junior Developer at Liisa +- Alexandre Collignon: UX/UI designer, Head of Marketing & Community at Liisa + +### Contact + +- **Contact Name:** Bernardo Silva +- **Contact Email:** bernardo@liisa.io +- **Website:** www.liisa.io + +### Legal Structure + +- **Registered Address:** Rua José Henriques Coelho 3, 6C, 2770-103, Paço de Arcos, Lisboa, Portugal +- **Registered Legal Entity:** Vírgula Pragmática LDA, VAT: PT517151006 + + +### Team's experience + +#### Bernardo +As Liisa's co-founder and CEO, Bernardo Silva leads a pioneering company leveraging big data for insightful NFT investor decisions. His leadership roots back to Deloitte, managing business consultations and cost-saving initiatives. His strategic role in an EU Digital Transformation Project and the launch of Portugal's largest Energy provider's loyalty program spotlight his tech project management prowess. His time at IKEA Portugal birthed a robust in-store capacity planning framework based on predictive analytics. An Industrial and Civil Engineering graduate, his focus lies in data-driven decision making in Web 3, with a proven ability in steering innovative projects and entrepreneurial initiatives. + +#### Paulo +Paulo Peixoto, Co-founder and CTO of Liisa, is an experienced technical leader with a rich background in full-stack development and specialized proficiency in blockchain data APIs and stream APIs, having experience with EVM NFT data. His expertise has been instrumental in developing Liisa's NFT trading analytics platform, embedding AI into backend processes and extracting and analyzing both real-time and historical NFT data. Formerly at Rainplan, he spearheaded a team to design a unique platform connecting real estate owners with government incentives. His further technical acumen was demonstrated at Updone as a co-founder, where he designed and implemented a custom-made CRM. In his roles at Loxo, Remi, Hardcopy, and MyMedCard, Paulo improved app performance, amplified system analytics, and led solution development. With a CertHE in Banking, Corporate Finance, and Securities from the University of Bedfordshire, Paulo skillfully combines technical mastery with financial knowledge. + +#### Kerim +Kerim Caner Tümkaya is an accomplished Senior Data Scientist at Liisa, specializing in leveraging AI models to extract valuable insights from NFT data. With a profound mastery of data science and a diverse technological skill set, Kerim excels in machine learning, data analysis, and Python programming. Additionally, he possesses advanced cloud engineering skills, effectively utilizing platforms such as Cloudera, GCP, and AWS. Throughout his career, Kerim has made significant contributions in the field of data science. Notably, at Hepsiburada, he applied his expertise in demand and risk modeling, while at Allianz Türkiye, he developed machine learning projects for the banking sector. Kerim's repertoire includes proficiency in Pyspark, Hive, Impala, SQL, R, and GCP, enabling him to tackle complex challenges across various industries. + +#### Guilherme +Guilherme, Junior Backend Developer at Liisa, is a distinguished Computer Science graduate from Instituto Superior Técnico in Lisbon. He stands out with his exceptional academic performance, particularly in areas such as Object-Oriented Programming, Machine Learning, and Distributed Systems. His notable projects include implementing a multi-connection File System, a user-friendly crypto mobile app, and an online currency distributed system, demonstrating profound skills in Python, Java, and C/C++. His contribution to the development of Liisa's NFT trading analytics platform underpins his extensive expertise. Guilherme's versatility, combined with his commitment to every phase of project execution, emphasizes his exceptional technical competence. + +#### Alexandre +Alexandre Collignon is a professional with expertise in product design and experience in the NFT market. As the Head of Marketing and Community at Liisa, he engages with NFT traders daily and understands their needs and preferences. With a background in digital marketing and experience as a Digital and Technology Consultant at EY and Accenture, Alexandre brings a strategic and innovative approach to product design. He has led the development of AI-enabled platforms, resulting in efficiency gains for major industry players. Alexandre's past experiences in front-end development enhance his ability to create intuitive and engaging designs. With his understanding of the NFT market and experience as a trader, Alexandre aims to elevate Liisa's product design and deliver value to the community. + + +### Team Code Repos + +Source codes will reside in +- https://github.com/LiisaNFT + +For further reference +- https://github.com/paulogustavopeixoto +- https://github.com/guilhermeleitao2002 +- https://github.com/kerimtumkaya +- https://github.com/alexcollignon + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/bernardo-silva-631149161/ +- https://www.linkedin.com/in/pauloassispeixoto/ +- https://www.linkedin.com/in/kerim-caner-tumkaya/ +- https://www.linkedin.com/in/guilherme-leit%C3%A3o-47bb27192/ +- https://www.linkedin.com/in/alexandre-collignon/ + +## Development Status :open_book: + +Our team has brought the first iteration of the portfolio tracker mockups to fruition (please see them below in the Mockups section). + +In a proactive endeavor to understand and address the data-related challenges of building the MVP, we have exchanged several emails and engaged in multiple meetings with the Parity team. Through these communications, we ensured technical feasibility of the proposed approach and refined the data approach and mockups to better match the ecosystems' needs. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **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:** 2.5 months +- **FTE:** 2.5 +- **Costs:** 17,000 USDC + +| Number | Deliverable | Specification | +| ------ | ------------------------- | ------------- | +| 0a. | License | All code will be open-sourced under Apache 2.0 license. | +| 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) 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. | + + + + +### Milestone 2 — Portfolio tracker front-end implementation + +- **Estimated Duration:** 2.5 month +- **FTE:** 2.0 +- **Costs:** 13,000 USD + +| Number | Deliverable | Specification | +|-------:|--------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | Documentation includes Inline Code Documentation, Configuration Documentation, Readme file | +| 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. | +| 0e. | Article | Write a Medium article that explains the work done as part of the grant. | +| 1a. | Bubble.io wallet plugins | Design and engineer custom Bubble.io plugins for the selected wallets. The plugins will be architected to integrate wallet log-in (signature) into our front-end application interface. The plugins will be published on the Bubble.io marketplace and made freely available to the wider developer community. Selected wallets: Subwallet, Fearless wallet, Nova Wallet, Talisman. This will be developed using Javascript. | +| 1b. | Wallet address transmission | Implement a front-end authentication module that captures and transmits wallet addresses from the user sign-in process to our backend. The transmission activates event-driven triggers, initiating Subsquid API queries for relevant event data retrieval. This will be developed using Node.js and React.js. | +| 2a. | Dashboard Structure Implementation | Utilizing provided mockups as the architectural blueprint, implement the user interface for the application dashboard. This involves arranging key performance indicators (KPIs) and various data visualization elements according to the predefined design. This will be developed using React.js. | +| 2b. | Dynamic Dashboard Values | Implement a real-time data binding mechanism that retrieves and displays updated portfolio data from the database, activated by event-driven triggers as defined in 1b. This will be achieved using a websocket client connected to our PostgreSQL Database. | + +## Mockups + +### Portfolio Overview + +The homepage of the portfolio provides a quick and insightful summary of the user's NFT holdings, including key features such as: +- Overview Metrics: Displaying estimated portfolio value, revenue from NFT sales, spending on NFT purchases, realized profit-and-loss, and unrealized profit-and-loss; +- Portfolio Scorecard: Assessing liquidity, volatility, and diversification of the NFT portfolio; +- Portfolio Evolution Chart: Visualizing the historical value evolution of the NFT portfolio; +- Inventory Chart: Illustrating the relative value distribution of each NFT holding. +- Collection Highlights: Ranking collections in the user’s wallet based on top gainers, top losers, and recent purchases. + +![Portfolio tracker #1 (1)](https://github.com/LiisaNFT/W3F-Grants-Program/assets/139144686/ae122745-4d96-4c2a-86af-a8bc8230f63a) + +### NFTs page + +The NFTs page offers users a technical and visually engaging interface to view their NFT collection: +- NFT Images: Displaying artwork and associated metadata for each token; +- Token Metrics: Showing estimated value, acquisition price, unrealized PNL, and 24-hour sales for each collection; +- Filtering and Sorting: Allowing users to sort and filter NFTs based on metrics like collection sales and estimated value. + +![Portfolio_tracker_2_1](https://github.com/LiisaNFT/W3F-Grants-Program/assets/139144686/ca77234f-dba4-4ede-8860-981d958ba3fd) + + +### Individual item page + +The individual item page allows users to delve into the comprehensive details of each NFT from their collection, providing a technical and in-depth analysis of the specific token. +- NFT Images: Showcasing artwork and associated metadata. +- Token Metrics: Providing estimated value, last sale price, unrealized PNL, acquisition date, and rarity rank within the collection. +- Historical Chart: Visualizing sales history and estimated value evolution over different timeframes. +- Activity Table: Logging all events related to the NFT, including sales, transfers, and minting. + +![Portfolio tracker #3 (1)](https://github.com/LiisaNFT/W3F-Grants-Program/assets/139144686/9ce0f425-3e2e-4901-9bd5-d68817afc3b4) + + +### Collections page + +The collections page provides users with an aggregated view of their NFT holdings by collection, allowing them to assess collection performance and its impact on their portfolio. +- Metrics per Collection: Includes NFTs owned, sales floor and % change for a timeframe, total invested value, estimated value, unrealized PNL, and collection volume. +- Filters and Sort: Users can compare values in native tokens or dollars, select timeframes, and sort the table by various metrics. +- Search: Quick search bar filters the table dynamically as the user types, facilitating collection analysis. +- This page offers a concise and efficient way for users to evaluate the performance and contribution of each NFT collection in their portfolio + +![Portfolio tracker #4 (1)](https://github.com/LiisaNFT/W3F-Grants-Program/assets/139144686/12288478-21f2-4fab-9269-dfdc20693ed8) + +## Future Plans + +Immediate Plans in the timeline includes +- User testing and improvements to the portfolio tracker +- Integrating the portfolio tracker as part of the Liisa multi-chain NFT analytics platform +- Integrate NFTs from the supported protocols in the Liisa multi-chain NFT analytics platform + +Our Roadmap includes +- User-defined alerts for NFT events +- Integration with NFT marketplaces for off-chain data querying, specifically marketplace listings and bids +- Integration of AI models for NFT valuations +- Development of a mobile application +- Integration of additional protocols +- Token tracking + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +From talking to the Parity Team + +**What work has been done so far?** +We have developed and deployed the Liisa NFT analytics platform, currently supporting ETH and MATIC NFTs, including both off-chain and on chain data visualizations and KPIs + +**Are there are any teams who have already contributed (financially) to the project?** +Yes, our Incubator and VC + +**Have you applied for other grants so far?** +No diff --git a/applications/Lollipop.md b/applications/Lollipop.md new file mode 100644 index 00000000000..baff497eea4 --- /dev/null +++ b/applications/Lollipop.md @@ -0,0 +1,224 @@ +# Lollipop: sBPF Runtime as a Service on PolkaVM + +- **Team Name:** Lollipop Builders +- **Payment Details:** + - **DOT**: 13W1E9hU8oKgVL1uaAGYTFLY9G1q2YJTjrVN5YEhUoXM4QHT + - **Payment**: 13W1E9hU8oKgVL1uaAGYTFLY9G1q2YJTjrVN5YEhUoXM4QHT (USDC), 50% USDC and 50% in vested DOT +- **[Level](https://grants.web3.foundation/docs/Introduction/levels):** 3 + + +# Project Overview :page_facing_up: + +### Overview + +**Tag line:** **Lollipop** - modular framework for Solana and SVM, based on Polkadot JAM and PolkaVM. + +**Brief description:** Lollipop is a provider of modular solutions for Network Extensions/Solana L2/Rollup with diverse execution environments that can broadly be categorized as middlewares and instances. As opposed to Layer 2 solutions, Network Extensions does not result in liquidity or user fragmentation. Lollipop is an extension of Solana's monolithic infrastructure. NES environments can include TEEs, co-processors, zk-encryption, FHE, trusted solver networks, AI agents and more, even in non-blockchain contexts. Lollipop Instances and Middlewares do not rely on cross-chain technologies for integration with Solana. Instead, they interconnect via Solana itself, utilizing program delegation, preserving direct connectivity without bridges. + +**Integration into Polkadot:** Polkadot JAM in emulating SVM execution with PolkaVM, which is RISK-V level virtual-machine, so users may use SVM programs with Polkadot’s JAM, just like Mac users can run windows app with emulators like Parallels Desktop. With this being successful, the Execution Environment (VM) Fragmentation will be gone completely. +sBPF Runtime as a Service in PolkaVM - is a middleware that will enable running SVM-related environments, taking full advantage of PVM and increasing Polkadot utilisation through synergies with the Solana and SVM-based ecosystems. + +**Motivation:** The Lollipop team is made up of members who are deeply immersed in Polkadot, Solana, and other ecosystems. Being inspired by the opportunities presented by the Polkadot JAM along with understanding the functional bottlenecks for Solana led us to the vision for Lollipop. We came to the conclusion that a modular framework based on Polkadot technologies with the widest customization possibilities is ideal for both the Solana ecosystem and for running individual spaces (runtimes) based on PVM combined with sBPF. + + +### Project Details + +**Overview of the Technology Stack** +- **PolkaVM** – The execution environment for running sBPF programs. +- **sBPF Runtime** – Embedded sBPF interpreter to support Solana smart contracts. +- **Rust** – Primary development language for modifying the sBPF interpreter and integrating it with PolkaVM. +- **jam-pvm-common** – Provides common utilities for interaction with PolkaVM. +- **Solana Program Library (SPL) Support** – To enable compatibility with existing Solana contracts. + +**PoC/MVP or Other Relevant Prior Work** +- **Concept Validation:** Discussions with Dr. Gavin Wood on feasibility. +- **Technical Research:** Published article ["sBPF Program Execution on PVM - HackMD"](https://hackmd.io/@clearloop/rk6JhtdK1g). +- **On-going Work:** Adaptation of 'anza-xyz/sbpf' for no_std execution. +- **Initial Feasibility Testing:** Binary profiling and testing of execution overhead. + +**Data Models / API Specifications of the Core Functionality** + +The sBPF Runtime Feasibility & Prototype Development in PolkaVM aims to evaluate whether sBPF programs can be executed inside PolkaVM with modified sBPF runtime, with a minimal prototype that includes basic contract execution and result storage, the API specifications focus on: +1. Submitting an sBPF program for execution in PolkaVM +2. Retrieving and storing execution results +3. Validating the feasibility of state management + +**Execution API (Minimal Prototype Scope)** +- Purpose: Allows an off-chain service to submit a precompiled sBPF program for execution inside PolkaVM. +- Input: + - 'program_id': Unique identifier of the sBPF contract + - 'execution_params': Parameters for the execution (e.g., function input, gas limit) +- Output: + - Execution logs (`stdout`, `errors`, `syscall output`) + - State difference (`{storage_addr: old → new}`) + +**State Diff & Result Storage API** +- Purpose: Stores execution results outside of PolkaVM for later verification. +- Input: + - `execution_id`: Unique execution session ID + - `state_diff`: Key-value pairs of changed state values + - `logs`: Execution logs for debugging +- Output: + - Confirmation of successful storage + +> **Please Note:** +> - The state difference is stored in an external DB rather than committed to blockchain storage. +> - This ensures minimal modifications to PolkaVM while still capturing execution feasibility. + +**Documentation of Core Components, Protocols, Architecture:** +The architecture for this feasibility study and prototype development is designed to: +- Execute a basic sBPF contract (counter program) inside PolkaVM +- Store the execution results externally +- Validate whether execution is feasible within PolkaVM’s constraints (4MB limit, memory access, syscalls, etc.) + +We have justified the need for a modular solution for Solana in detail in a number of our researches and observations: + - https://hackmd.io/@clearloop/rk6JhtdK1g + - https://www.lollipop.builders/Lollipop%20Network%20Extensions%20Report.pdf + - https://www.lollipop.builders/research + - https://medium.com/lollipop-builders/trump-and-melania-transactions-failure-investigation-b2a5c54d2021 + - https://medium.com/lollipop-builders/how-lollipop-is-turning-solana-into-a-modular-playground-for-developers-c715262a5a1e + +**Business-oriented activities (marketing, business planning), events or outreach:** +At the moment, the test environment is in the process of being deployed. We are currently working with Mantis, RWA business, perp dexes and we are also developing a presence in the gaming sector. Lollipop also has arrangements with RWA business, RWA business which will issue tokens and be regulated by the HK authorities based on Solar power plant receivables for the next ten years. We are also in the process of discussing engagement with marketing agencies such as Market Across and Cointelegraph. +The other most important domain for Lollipop is PayFi. Demand for crypto-based infrastructure and stablecoins is growing from FinTech and banking. This includes the creation of new financial primitives for payment functions with financial services based on blockchain technology and smart contracts. For PayFi, it is critically important that transaction costs remain minimal and predictable. +To fully deploy PayFi infrastructure, it will be necessary to implement Lollipop modules, which will facilitate off-chain processing with predictable costs combined with all the benefits of JAM and PolkaVM. Additionally, NE can assist in ensuring compliance and regulatory adherence for payment applications across different regions by utilising the Solana Permissioned Environment with JAM. + + +### Ecosystem Fit + +**Where and how does your project fit into the ecosystem?** +The sBPF Runtime as a Service in PolkaVM will bring value to Polkadot by connecting to the huge ecosystem and user base of SVM-based spaces (including Solana and other ecosystems like Eclipse, Termina and so on). PVM capabilities will enhance SVM frameworks by introducing additional functionality. This implies many different network effects and utilisation by shifting both user and economic load to the Polkadot tech stack, with the introduction of fundamentally new economic models targeting enterprise customers, institutional players, users, and infrastructure providers. + +**Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** +In the context of "sBPF Runtime as a Service in PolkaVM", the proposed solution targets the user and developer base of Solana, Polkadot, and SVM-based L1/L2 ecosystems. The Runtimes/Environments are designed for different use cases: +- **Solana-related dApps and Protocols:** Off-chain process handling will enable the creation of highly customizable execution environments tailored to various requirements and tasks, with direct connectivity to Solana. +- **Isolated customizable execution environments:** Designed for diverse applications such as Perp DEXes, Gaming, Oracles, enterprise, and government solutions. +- **Developers:** Our solution expands development opportunities by seamlessly bridging different developer cohorts through the introduction of new tools and primitives. +- **Users:** the customizability of runtimes will open up new capabilities not available to institutional and enterprise customers in Solana and SVM forks +- **Polkadot ecosystem participants:** validators, delegators, developers. + +**Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** +Previously, the Polkadot community considered proposals for deploying SVM on Parachains **[(link)](https://forum.polkadot.network/t/solana-parachain/7055)**. However, this approach involved significant trade-offs due to the architecture of Polkadot 1.0 and required a compatibility layer for the Substrate node to function as a Solana node. The constraints related to performance limitations and the need to develop an ecosystem around a Solana fork within a Parachain—without providing tangible benefits to either the Solana or Polkadot ecosystems—rendered this idea impractical. +In the case of Lollipop, JAM is used as the primary execution layer. Moreover, it is an application-specific implementation rather than merely a fork of Solana, as in the approach described above. + +**Are there any projects similar to yours in related ecosystems?** +The approach presented by Lollipop using PolkaVM, as far as we know at the moment, has no alternatives also in other ecosystems and is unique. Restaking platforms can be considered somewhat conceptually related, as they enable the deployment of Actively Validated Services (AVS) within specific environments. Some Solana/SVM-related projects refer to themselves as Network Extensions, but in most cases, they are standard rollups (e.g., Soon SVM as an optimistic rollup, Termina as RaaS) or sidechains (e.g., Neon EVM) without seamless integration into the Solana. + + +## Team :busts_in_silhouette: + +### Team members + +- Name of team leader: Qinwen Wang +- Names of team members: Kyle Gu, Tianyi , Stepan Soin, Wu, James Wade + +### Contact + +- **Contact Name:** Qinwen Wang +- **Contact Email:** qinwen@lollipop.builders +- **Website:** https://www.lollipop.builders/ + +### Legal Structure + +- **Registered Address:** Chambers, Road Town, Tortola VG1110, British Virgin Islands +- **Registered Legal Entity:** Lollipop Builder Ltd. + +### Team's experience + +The Lollipop team consists of experienced cryptographers, developers and crypto builders and is focused on building Network Extensions for Solana using Polkadot technologies. +- **Qinwen Wang:** CEO, Founder. 4 years in Web3 foundation; Producer of "Virtual Niche" - the World's first Crypto Art NFT Museum Exhibition; Curator and lecturer for Christie's NFT 101 HK & London; Curator and collector of Sotheby's metaverse auction; Angel investor, Forbes 30U30. +- **Kyle Gu:** Founder’s office. MSC in Actuarial Science & PD in Computer Science of University of Kent; Over 8 Years of development operation experiences for crypto projects; Prev Magnet Network Project Manager; Prev Darwinia Network BD Manager. +- **Tianyi:** Head of JAM Implementation. Author of Spacejam Network, Zink language contributor, prev developer and top 5 contributors of GEAR, prev developer in Chainsafe. +- **Stepan Soin:** Head of Research. 4 years General manager and ecosystem researcher at Avalanche, Researcher and Coordinator at Dehales Capital, VC Investment analytics Cryptomeria Capital. +- **Wu:** Lead developer. Expert in VM compilation and cross-platform compatibility, specializing in EVM, WASM, and BPF. Designs efficient toolchains for seamless smart contract execution across Ethereum, Polkadot, and Solana. Proficient in Rust, developing blockchain nodes, VM runtimes, and cross-chain protocols with a focus on security, efficiency, and high-performance computing. +- **James Wade:** Developer. Expert in blockchain architecture and protocols across Bitcoin, Ethereum, Polkadot, and Solana. Specializes in cryptographic algorithms and cross-chain interoperability, designing secure and efficient multi-chain asset exchange and data transfer solutions for decentralized environments. + +### Team Code Repos +- https://github.com/HONGYI-SD +- https://github.com/clearloop +- https://github.com/lei-1993 + +### Team LinkedIn Profiles (if available) +- https://www.linkedin.com/in/qinwenwang/ +- https://www.linkedin.com/in/kyle-gu/ +- https://www.linkedin.com/in/stsoien/ + + +## Development Status :open_book: + +At this stage, development has not yet commenced. However, significant groundwork has been completed to ensure a well-structured and feasible implementation of sBPF Program Execution on PolkaVM. +1. **Technical Design & Research** + - We have formulated a detailed approach for executing sBPF programs in PolkaVM, which is documented in the article: **[sBPF Program Execution on PVM - HackMD](https://hackmd.io/@clearloop/rk6JhtdK1g#Specification)**. + - This document outlines the key architectural decisions, execution flow, and potential challenges, particularly addressing the 4MB PolkaVM service limit. +2. Discussions with Key Experts + - We have engaged in multiple discussions with Dr. Gavin Wood, both via email and in face-to-face meetings, to validate our approach. + - These discussions have provided valuable insights into optimizing execution, handling state validation, and ensuring efficient integration with Polkadot’s ecosystem. +3. Next Steps + - With the technical research phase complete, we are now prepared to begin actual development. + - The next milestone will focus on compiling and testing the feasibility of embedding sBPF in PolkaVM, followed by state validation and execution optimization. + +## Development Roadmap :nut_and_bolt: + +### Overview + +This roadmap outlines the phased development of the sBPF Runtime as a Service in PolkaVM, ensuring that Solana smart contracts can execute efficiently within Polkadot’s infrastructure. Given the 4MB size constraint of PVM services, the roadmap prioritizes feasibility analysis, optimization, and transaction processing integration. +- **Total Estimated Duration:** 8 weeks +- **Full-Time Equivalent (FTE):** 3 +- **Total Costs:** $65,000 USD +- **DOT %:** Percentage of Total Costs to be paid in vested DOT: 50% + +### Milestone: sBPF Runtime Feasibility & Prototype Development in PolkaVM + +- **Estimated duration:** 8 weeks +- **FTE:** 3 +- **Costs:** $65,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | Initial architecture documentation explaining sBPF execution in PVM | +| **0c.** | Testing and Testing Guide | Unit tests to measure compiled sBPF interpreter size | +| **0d.** | Docker | Containerize and run Minimal sBPF Execution Test in PVM using Docker | +| **0e.** | Article | Publish an article outlining feasibility analysis and prototype development | +| 1. | Compile `anza-xyz/sbpf` with 'no_std' and analyze feasibility | Analyze feasibility of `no_std` adaptation and remove Solana-specific dependencies | +| 2. | Memory & Execution Profiling for Minimal sBPF | Measure compiled binary size, execution time, and memory footprint for minimal sBPF programs. | +| 3. | Fork `anza-xyz/sbpf` & Introduce PVM Service (`jam-pvm-common`) | Refactor sBPF interpreter to work as a PolkaVM service using `jam-pvm-common`. | +| 4. | Compile & Measure sBPF Binary Size | Ensure it fits within 4MB PVM service limit. | +| 5. | Solana Account Model Integration | Port Solana’s account model. | +| 6. | Minimal sBPF Execution Test in PVM | Deploy and execute a simple contract (e.g., counter) in PolkaVM to confirm functional sBPF execution. The result of execution to be stored in a separated DB. | + + +## Future Plans + +Lollipop is committed to expanding Polkadot's execution capabilities by enabling Solana sBPF program execution within PolkaVM. Our work on sBPF Runtime as a Service in PolkaVM is just the first step toward a broader cross-ecosystem compatibility strategy. + +In the near future, we aim to: + +**1. Integration of Solana Account Model, Parallel Tx Scheduling, Interoperability & Compatibility** + - Parallel TX Scheduling: We think everything will work sequentially at this stage, yet we also believe we can port everything Solanas has into our PolkaVM-based runtime, like Parallel TX Scheduling, and we expect some obstacles and stumbling blocks for this issue, but will be properly addressed. + - Interoperability & Compatibility: Our goal is to offer a commercial-ready system that's fully familiar to Solana developers. Apart from this grant, We're also integrating common Solana runtime dependencies (e.g., SPL libraries) to support standard interfaces with minimal changes. Our goal is to offer a commercial-ready system that's fully familiar to Solana developers. +We are also planning Interoperability with Solana through lightweight instruction programs and post-execution callbacks, allowing NE-executed transactions to trigger on-chain logic. + +**2. Scale Up Development & Deployment** + - Complete the implementation and optimization of sBPF execution in PolkaVM with multiple PVM services, + - Deploy this execution layer, ensuring efficient performance and seamless interaction with Solana’s state model. + +**3. Enhance Compatibility & Performance** + - Investigate additional optimizations to improve the efficiency and security of sBPF execution. + +**4. Expand Developer Adoption** + - Provide SDKs and tooling to help developers port and deploy Solana smart contracts to Polkadot. + - Offer comprehensive documentation and examples to simplify integration. + +**5. Long-Term Vision: Unified Execution Layer** + - This initiative aligns with Lollipop’s broader vision of creating a unified execution layer across multiple ecosystems. + - In future iterations, we plan to extend PolkaVM’s support beyond Solana’s sBPF to other high-performance execution environments, such as AI-based computation or modular rollups. + +Our goal is to position Lollipop as a key infrastructure provider, bridging execution environments across Polkadot, Solana, and beyond. + + +## Additional Information :heavy_plus_sign: + +- Lollipop is an innovative project focused on bridgeless scaling and execution infrastructure for Solana with Polkadot JAM. Unlike traditional Layer 2 solutions, Lollipop’s Network Extensions (NEs) leverage cryptographic proofs and diff-based validation to ensure trustless execution without additional verification overhead. +- Our work on sBPF Runtime as a Service in PolkaVM represents a significant advancement in multi-chain execution compatibility, allowing Solana smart contracts to run seamlessly within Polkadot without needing a bridge. +- This initiative has already gained attention within the Polkadot and Solana communities,as we move forward, we look to collaborate with both the Polkadot and Solana ecosystems to ensure this technology benefits developers, validators, and users alike. diff --git a/applications/LunoKit.md b/applications/LunoKit.md new file mode 100644 index 00000000000..48eca9d957c --- /dev/null +++ b/applications/LunoKit.md @@ -0,0 +1,234 @@ +# LunoKit + +- **Team Name:** LunoLab +- **Payment Details:** + - **DOT**: 14pGVuuBxbN9dVNGh2a6dNqAEP7f48z7ks5vH9WNXKakUm7Z + - **Payment**: 14pGVuuBxbN9dVNGh2a6dNqAEP7f48z7ks5vH9WNXKakUm7Z (USDC). +- **Level:** 2 + +## Project Overview :page_facing_up: + +### Overview +LunoKit is the core open-source product developed by the Lunolab team, aiming to build a customizable UI-themed, developer-friendly Web3 account connection infrastructure for the Polkadot ecosystem. It unifies wallet connection state management, account abstraction, chain switching, and session recovery, while also providing a rich set of UI components and multi-chain account support, greatly reducing the integration threshold for DApps built on Polkadot SDK chains. +As a frontend development library based on React + TypeScript, LunoKit also provides over 20 Hooks, including account state management, chain switching, connection control, and on-chain data subscription, with support for data caching. Developers can focus on core business logic while LunoKit handles the account module. + +### Project Details + +#### 1. User Interface Component Design +LunoKit will provide a set of React UI components for account connection, covering common functionalities such as connect button, wallet selection modal, account details modal, network switcher, and asset display panel. All components are responsive, adapting to both mobile and desktop, and support custom themes. +![ui](https://github.com/user-attachments/assets/d6c555ca-4ec6-4952-844f-ea3cbb157d8c) + +#### 2. Architecture Design and Core Modules + +LunoKit adopts a clear three-layer modular architecture, handling connection logic, React integration, and UI presentation respectively: + +#### `@luno-kit/core` +Encapsulates wallet connectors, chain configuration, and account management underlying logic, providing unified connection states and signer interfaces. + +#### `@luno-kit/react` +The integration layer built with React, providing over 20 composable Hooks for managing connection states, chain switching, and on-chain data subscriptions. + +Common Hooks examples: + +- `useAccount()` / `useAccounts()` +- `useConnect()` / `useDisconnect()` +- `useChains()` / `useSwitchChain()` +- `useSubscription()` / `useBalance()` / `useBlockNumber()` +- `useSendTransaction()` / `useSignMessage()` / `useSigner()` + +#### `@luno-kit/ui` +Provides plug-and-play components such as connect buttons, account panels, and network switchers, supporting style and theme customization. + +### Tech Stack Overview +| Technology | Purpose | Module | +|--------------------------|--------------------------------------------|----------------------------| +| TypeScript | Type safety, improved development efficiency | All modules | +| React 18 | Building UI and lifecycle logic | @luno-kit/react, @luno-kit/ui | +| Zustand | Centralized state management (connection state, accounts, chain) | @luno-kit/react | +| TanStack React Query | On-chain data subscription, cache updates | @luno-kit/react, @luno-kit/ui | +| Dedot | Lightweight and modern Polkadot API alternative, better performance and smaller bundle size | @luno-kit/core, @luno-kit/react | +| Tailwind CSS 4.x | Responsive component styling | @luno-kit/ui | +| Radix UI | Accessible interactive component foundation | @luno-kit/ui | + +### Ecosystem Fit + +#### Target Audience of LunoKit: +- **Parachain development teams**: Need to quickly integrate account connection modules into chain websites, governance platforms, or marketing pages. +- **DApp development teams**: Teams building DeFi, NFT, DAO, GameFi, etc., often facing challenges of multi-wallet compatibility and connection state management. +- **UI developers**: Seeking accessible, theme-customizable, componentized wallet connection UIs. +- **Polkadot hackathon participants / startups**: Strong demand for "out-of-the-box" components to achieve high-quality connection experiences within limited time. + +#### What real needs does LunoKit address? + +In Polkadot/Substrate frontend development, developers have long faced issues such as inconsistent wallet access logic, complex state management, and lack of standardized UI. LunoKit systematically addresses the following key needs: + +- **Unified multi-wallet connection** + Supports major injected wallets such as polkadot.js, Talisman, SubWallet, and NovaWallet. Provides a unified connector abstraction and type system to avoid high costs and errors caused by wallet interface differences. + +- **Standardized account & connection state management** + Encapsulates connection state, current account, wallet source, chain info, and authorization state into a unified state model. Combined with React Hooks, provides highly composable integration and avoids repetitive logic in DApps. + +- **Multi-chain adaptability** + Supports custom chain configuration and inter-chain switching, compatible with multi-parachain scenarios, suitable for multi-chain deployment applications. + +- **Plug-and-play connection UI components** + Provides customizable connect buttons, account panels, network switchers, and asset lists. Fully a11y compliant, improves UI consistency and efficiency, reduces repetitive implementation. Components are responsive, mobile-friendly, and support Deeplink-based flows for wallet apps like SubWallet. + +- **On-chain data subscription & caching** + Integrates Dedot and TanStack Query, encapsulates derive/storage query logic, supports auto-caching, state updates, and error recovery for efficiency and stability. + +- **Modern development process & framework support** + Offers integration templates for CRA, Vite, Next.js, combined with TypeScript-first experience, Hooks system, and modular architecture. + +- **Custom UI system, decoupling components & logic** + Core logic is provided as Hooks, enabling developers to skip default UI components and fully customize connect buttons, modals, etc., for diverse product styles and UX designs. + +- **PolkaVM Support** + After completing Substrate support, LunoKit will support PolkaVM, enabling simultaneous connections to Substrate and EVM accounts, boosting efficiency for Solidity DApp developers on PolkaHub chains. + +#### Similar attempts in Substrate/Polkadot/Kusama ecosystem: + +- **SubConnect**: It has not been updated for nearly a year, with multiple issues left unanswered by developers and the project in a stagnant state ([reference link](https://github.com/Koniverse/SubConnect-v2/issues)). We tested and found that some of its functions are no longer usable. In addition, it is built on top of web3-onboard, with the core library heavily dependent on web3-onboard, which limits its long-term maintainability. +- **Talisman Connect**: Officially deprecated ([issue](https://github.com/TalismanSociety/talisman-connect/issues/56)) +- **Dot-Connect**: The functionality is relatively limited, only supporting basic wallet connection features and lacking a complete account module. The range of components is limited, and the UI and user experience quality are relatively weak. For development teams. + + +#### Key Advantages of LunoKit: + +- TypeScript-first type system, clear interface specifications. +- React Hooks-based modular encapsulation for state, accounts, chain switching, and subscriptions. +- Decoupled state management and connection logic—developers can skip official UI and still use Hooks to build custom UIs. +- Built-in customizable, responsive UI components (buttons, modals, switchers) with a11y compliance. +- Complete examples & docs to reduce learning curve. +- The core library is fully self-developed, does not rely on external repositories, and ensures controllable long-term maintenance and strong ecosystem adaptability. + + +In the broader Web3 ecosystem, comparable tools include: + +- **wagmi (Ethereum)**: React Hooks for wallet connection and state. +- **RainbowKit (Ethereum)**: Customizable wallet connection UI, designed to pair with wagmi. + +These are standards in Ethereum, but Polkadot lacks equivalents. LunoKit integrates both functionalities to fill this gap. + +## Team :busts_in_silhouette: +### Team members + +- Leader: Cris Sun +- Member: Brain (WBH) + +### Contact + +- **Contact Name:** Cris Sun +- **Contact Email:** lunolab1@gmail.com +- **Website:** https://www.lunolab.xyz/ + +### Legal Structure + +- **Registered Address:** - +- **Registered Legal Entity:** - + +### Team's experience + +**Lunolab** is composed of two core members with extensive blockchain development backgrounds. Since joining the **ChainX team** in 2020, they have been active in the Web3 field, participating in the incubation and development of multiple public chains and application projects. Cris has over 5 years of Web3 product experience, focusing on cross-chain protocol design and user experience optimization. He led the product design of ChainX, worked as a product manager responsible for OmniBTC’s frontend product design and project management, and from 2023–2025 served as the product lead of BEVM/GEB, overseeing chain-level functionality design and developer tool planning. Brain is a senior blockchain frontend developer. He joined the ChainX frontend team in 2020, began leading the frontend system development of OmniBTC in 2022 (including OmniSwap and OmniLending), and from 2023–2025 was fully responsible for the frontend architecture of BEVM/GEB, covering explorer, wallet, and developer tools, accumulating deep experience in blockchain frontend development. + +- **2020 – ChainX Team** + +- **June 2022 – OmniBTC (incubated within ChainX, now closed, social media [X](https://x.com/OmniBTC))** + OmniBTC was a cross-chain DeFi platform that included two core products: + - **OmniSwap**: A cross-chain trading aggregator supporting **40+ public chains** and **20+ cross-chain bridges**, with a cumulative trading volume exceeding **$2 billion**. + - **OmniLending**: A cross-chain lending platform with peak TVL of over **$10 million**. + +- **June 2023 – June 2025, BEVM (incubated within ChainX, later renamed [GEB](https://www.geb.network/))** + BEVM was a public chain developed with the Substrate technology stack, aiming to be a Bitcoin Layer 2 compatible with EVM smart contracts, with over **990,000 on-chain addresses**. + +### Team Code Repos + +- https://github.com/Luno-lab/LunoKit + +- https://github.com/wbh1328551759 (many non-open-sourced repos for GEB, contribution proof: [screenshot1](https://github.com/user-attachments/assets/de190fa2-3cff-486f-bcf0-4042cb8f1945), [screenshot2](https://github.com/user-attachments/assets/e8ef35ba-5a30-4345-a870-6b7f0989d47c)) + +- https://github.com/Gintma (Cris also has a certain development background and will be responsible for part of the UI-related code implementation) + +## Development Status :open_book: + +LunoKit has completed its initial version and has officially released a usable version. + +- **Demo Site** + https://demo.lunolab.xyz + +- **GitHub Repo** + https://github.com/Luno-lab/LunoKit + +- **Developer Docs** + https://docs.lunolab.xyz/ + + +## Development Roadmap :nut_and_bolt: +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2 +- **Total Costs:** 30,000 USD +- **DOT %:** 50% + +### Milestone 1 + +- **Estimated duration:** 1.5 months +- **FTE:** 2 +- **Costs:** 15,000 USD + +| No. | Deliverable | Specification | +|------|-------------|---------------| +| 0a. | License | MIT | +| 0b. | Documentation | Provide a complete online documentation site, including installation guide, quick start, API reference, and integration examples. The documentation should cover core concepts, connector usage, and configuration options. | +| 0c. | Tests & Test Guide | Core functionality is ensured through Vitest unit tests; covering connectors, utility functions, and configuration system. | +| 0d. | Build System | Complete monorepo build; TypeScript compiled using tsup, supporting both ESM and CJS outputs. | +| 0e. | Package Management | Use pnpm workspace and Changesets for version management and package publishing, supporting automated NPM publishing. | +| 1. | Core Module: `@luno-kit/core` | Implement core connector abstraction (`BaseConnector`), configuration system (`createConfig`), chain definitions (`Chain` type), and storage system; support custom API options and type definitions. | +| 2. | Wallet Connectors Collection | Implement 6 connectors: Polkadot.js Extension, SubWallet, Talisman, Polkagate, Nova Wallet, WalletConnect. Each connector supports account discovery, connection management, and signing. | +| 3. | Chain Configuration System | Pre-configure 6 chains: Polkadot, Kusama, Westend, Paseo,Polkadot AssetHub, Paseo AssetHub including RPC endpoints, SS58, token info, and icons; support custom Substrate chain configurations. | +| 4. | Utility Functions Library | Implement essential utility functions such as address format conversion, SS58 encoding/decoding, balance formatting, and device detection. | +| 5. | Type System | Provide full TS types (`Account`, `Chain`, `Config`, `Connector`, `Signer`, etc.) to ensure type safety. | +| 6. | UI Components: `@luno-kit/ui` | Implement 10 complete UI components: ConnectButton, ConnectModal, AccountDetailsModal, etc. | +| 7. | Demo Website | Provide a fully functional demo website. | + + +--- + +### Milestone 2 +- **Estimated Duration:** 1.5 months +- **FTE:** 2 +- **Costs:** 15,000 USD + +| No. | Deliverable | Specification | +|------|-------------|---------------| +| 0a. | License | MIT | +| 0b. | Documentation | Documentation expansion, including React Hooks API reference, UI component documentation, theme customization guide, and advanced usage tutorials. | +| 0c. | Tests & Test Guide | Provide comprehensive tests for React components and Hooks: components tested with React Testing Library, Hooks tested with Vitest; cover all core functionalities. | +| 0d. | Example Applications | Provide **4** complete examples: `with-vite` (Vite integration), `with-nextjs-app` (Next.js App Router), `with-nextjs-pages` (Next.js Pages Router), `with-cra` (Create React App). | +| 0e. | CSS Styling System | Complete styling system based on Tailwind CSS, providing `@luno-kit/ui/styles.css` and CSS variable support. | +| 1. | React Hooks: `@luno-kit/react` | Implement **22** Hooks. | +| 2. | State Management System | Lightweight state management based on Zustand, supporting connection state persistence, account management, and config caching; exposed through `LunoKitProvider` for app-level state. | +| 3. | Mobile Adaptation: `@luno-kit/ui` | Implement mobile wallet connection via Deeplink technology; includes device detection, UI adaptation, and auto-redirect logic. | +| 4. | Theme System | Theme system based on CSS variables, supporting custom themes. | +| 5. | API Integration Layer | Type-safe API layer based on Dedot; supports custom RPC calls and runtime version detection. | +| 6. | Development Tools Configuration | Complete engineering setup: ESLint, TypeScript, Vitest, pnpm workspace, tsup build, etc. | + + +## Future Plans :crystal_ball: + +In the short term, our focus will be on both enhancing LunoKit’s functionality and promoting it across the Polkadot ecosystem: + +- **More UI Components**: Add richer UI components, including advanced asset lists with NFT support and on-chain transaction history for addresses. +- **PolkaVM Support**: Continue developing support for PolkaVM, enabling developers to connect both Substrate-based accounts and EVM-based accounts simultaneously. This will significantly improve efficiency for those deploying Solidity DApps on PolkaHub chains. +- **Extended Wallet Support**: Integrate additional wallets such as Ledger, OneKey, Mimir, Fearless, and Polkadot Vault. +- **Multi-framework Frontend Support**: Extend beyond React to support frameworks such as **Vue** and **Svelte**, broadening accessibility for developers. +- **Web2 Social Login Exploration**: Explore embedded wallet solutions with Web2 social login (Google, GitHub, email) for smoother onboarding. +- **Ecosystem Promotion**: Increase exposure within the Polkadot ecosystem through collaboration with **OneBlock, OpenGuild, and PolkaWorld**, including launching tutorials, publishing technical articles, and conducting developer-focused courses. + +In the long term, our goal is to establish **LunoKit as the de facto wallet connection standard** for the Polkadot ecosystem, much like **wagmi + RainbowKit** in the EVM ecosystem. We aim to provide a unified developer experience across Substrate and EVM, multiple wallets, and frontend frameworks, making LunoKit the go-to infrastructure for DApp developers. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +### PolkaWorld diff --git a/applications/MAP-Bridge.md b/applications/MAP-Bridge.md index b5d7c2b637c..17fdb325f2b 100644 --- a/applications/MAP-Bridge.md +++ b/applications/MAP-Bridge.md @@ -1,5 +1,5 @@ -# Open Grant Proposal -* **Project:** Map Bridge +# Map Bridge + * **Proposer:** zcheng9 * **Payment Address:** 1CFM6QDvxwXEV3dUN9x2ftqq4rwAfkxN9W * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/89#issuecomment-792968983) diff --git a/applications/MIXER.md b/applications/MIXER.md index da578232c78..fa9c5ecaca0 100644 --- a/applications/MIXER.md +++ b/applications/MIXER.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Webb Mixer -* **Project Name:** Webb Mixer * **Team Name:** Webb * **Payment Address:** 0xAC8E9305dc7AC95685c7D52E759c35aCd9eB90Ff @@ -123,7 +122,7 @@ Definitions: Secret Key(S), Public key(P), Nullifier (N), Leaf(L), Hash function - Relation: H(S, N)=L - Proof of membership: User submits the path in zero knowledge - Public: R - - Private: MP - Vec<(Scalar, u8)> + - Private: MP - Vec\<(Scalar, u8)> - Relation: compute_root(H(S,N), MP) = R - Verify: - User submits N, ZKP diff --git a/applications/MIXERv2.md b/applications/MIXERv2.md index c971ee99af3..79ea5050c49 100644 --- a/applications/MIXERv2.md +++ b/applications/MIXERv2.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Webb Mixer Extended -* **Project Name:** Webb Mixer Extended * **Team Name:** Webb * **Payment Address:** 0xAC8E9305dc7AC95685c7D52E759c35aCd9eB90Ff @@ -106,7 +105,7 @@ Definitions: Secret Key(S), Public key(P), Nullifier (N), Leaf(L), Hash function - Relation: H(S, N)=L - Proof of membership: User submits the path in zero knowledge - Public: R - - Private: MP - Vec<(Scalar, u8)> + - Private: MP - Vec\<(Scalar, u8)> - Relation: compute_root(H(S,N), MP) = R - Verify: - User submits N, ZKP diff --git a/applications/Maki.md b/applications/Maki.md new file mode 100644 index 00000000000..54ebf93670b --- /dev/null +++ b/applications/Maki.md @@ -0,0 +1,185 @@ +# Maki + +- **Team Name:** Cyril Carlier (Individual) +- **Payment Address:** 0x8a0cFA1DE5c26e3Cd553F33Dc560fBfa5267867C (ERC-20 USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +- **Status:** Terminated + +## Project Overview :page_facing_up: + +This application is a response from the [anti-collusion infrastructure RFP](https://github.com/w3f/Grants-Program/blob/master/rfps/open/anti-collusion_infrastructure.md). + +### Overview + +Maki aims to be a simple MACI implementation for the Polkadot eco-system, similar to the existing one on Ethereum ([MACI](https://github.com/privacy-scaling-explorations/maci)) + +Maki is an ink! smart contract that implements a minimal anti-collusion infrastructure as specified in the following [specifications](https://github.com/privacy-scaling-explorations/maci/tree/9b1b1a631090ee89d2bc12f4bcef7763e42caef0/specs) and derived from [this ethresearch post](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413). This means that most of the project details are based on the researches done on [MACI](https://ethresear.ch/t/minimal-anti-collusion-infrastructure/5413) and the specifications. Things may differ by making Maki a more simple version of MACI. + +As explained in the RFP, the smart contract aims to allow users to vote on a quadratic voting and avoid/minimize the risk of collusion, keep the votes anonymous and allow the users to change their votes until the voting process ends. + +Governance is an important part of Polkadot and (even more for now I'd say) Kusama, while a a lot of use cases of governance mechanisms are already implemented and running on the ecosystems (via pallets and smart contracts), a voting system for quadratic voting, anonymous voting and anti-collusion is not available yet. +That is why the project fits well for Polkadot and Kusama. + +I'm interested in this project because governance is a major component in decentralized ecosystems and adding more needed possibilities to the panel of voting mechanism of Polkadot and Kusama seems important to me. +While for now I'm unsure the current projects on Polkadot/Kusama needs such mechanism, it is obvious some will need such anti-collusion and anonymous voting for its users. + +### Project Details + + +Following the specifications of MACI as linked above, here is an overview of the architecture and core functionalities of Maki. + +Maki is a smart contract that allow its users to vote while making collusion among participant difficult (if the operator is honest) and retain censorship resistance, correct execution and anonymity of votes. + +Maki has two kind of users: one **operator** and 0..n **voter(s)** (also called user here under). + +The operator role is to deploy the contract (and publish his public key, known by all), start the sign-up period (which is done when the contract is deployed), process all the voters commands, generate the result of each commands, tally the votes and generate a zk-SNARK proof that the result is valid. + +The voter role is to sign-up for a vote and then vote. + +Secrecy of the votes are possible by using cryptographic operations. As described in the MACI specs, each users and the coordinator have a key-pair used to publish encrypted messages and for the coordinator to decrypt those messages. + +#### Overview : + +![](https://i.imgur.com/n4tmk6p.png) + +#### Maki's Functions : + +`signUp` allows a user to register for voting by sending his public key to the contract. There is no need for a given user to call this function multiple times. + +`publishMessage` allows a user to vote. A voter may use this multiple time to change his vote options, as long as the vote in not ended. + +`processMessages` function called by the coordinator to process all the users' messages, update the state root and provide a zk-snark proof. + +`proveVoteTally` to publish the vote result and the zk-snark proof of it. Called by the coordinator. Can only be called once the vote ended. + +`verifyVoteTally` to verify that the generated zkSnark proof is valid. + +Public functions are needed for the coordinator to process the votes off-chain (basically the contract's state such as stateTree, messageTree, etc.) and the voter to get the coordinator's key. + +Besides the contract, we will provide two circuits to build the zk-Snark proof off-chain, one for the correctness of message processing (`proveStateCorrectness`) and one for the vote tallying (`proveVoteTallyCorrectness`). The circuits will be written in [circom](https://docs.circom.io/) and it will be used through a script that build and execute the compiled circuit. This is needed for the coordinator's functions `processMessages` and `proveVoteTally`. + +Maki has two merkle roots, one for the `messageTree` (which gathers submitted messages) and one for the `stateTree` (which gathers the mapping between the user public keys and the votes). + +Maki will be implemented as an ink! smart contract, so it will be developed in Rust with ink! library. + +Maki will _not_ provide out-of-the-box choices of circuits used for zk-SNARK proof (as it may vary depending on the nature of the voting system), nor choices of the type of voting mechanism (non-quadratic votes, conviction votes, different tallying (such as what can be found on Polkadot and Kusama referenda), etc.). However this could be part of a maintenance program, a future plan, and/or another team may develop these features to meet their needs. + +The goal being to have a functioning contract, the circuit is not my main concern here.Therefore, an existing circuit will be reused (in Typescript) - most likely one that is implemented by [MACI](https://github.com/privacy-scaling-explorations/maci). I'll give full credits to their implementation, even if this requires some adaptations on my end. + +### Ecosystem Fit + +Maki can be used in any blockchain that supports ink! smart contracts. + +It can be reused - as provided or modified - by any blockchain, dApp, infrastructures, ... that wishes to provide a way to make quadratic votes for its users. + +I'm not aware of any similar project on Substrate. Despite that there are different existing voting mechanisms on Polkadot/Kusama, this one is the only one that would provide a quadratic, provable, anonymous and anti-collusion voting system. + +## Team :busts_in_silhouette: + +### Team members + +- Cyril Carlier + +### Contact + +- **Contact Name:** Cyril Carlier +- **Contact Email:** cyrilcarlier@hotmail.com + +### Legal Structure + +Individual / Sole Proprietor + +### Team's experience + +I'm a software developer with 5 years of relevant experience in C#/.Net, Java(with Spring/Hibernate), Typescript, React, C++, SQL and Angular, working mainly on DDD projects and lower-level projects (such as background-jobs services, multi-thread related projects). I have a master degree in Computer Science (University of Namur - Belgium). + +Here is an overview of different relevant project I've worked / working on : + +* [Polk-auction](http://www.polkauction.io/): A project funded by this program ([polk-auction application](https://github.com/w3f/Grants-Program/blob/2606f01f2fed14bb358560c8ececc9ad05e40bb8/applications/polk-auction.md)) which is a project that allow Polkadot and Kusama end-users to have a concise, simple an easy to understand view of the parachain, auction and crowdloan state of the Dotsama's ecosystem. Focused on on-chain data with some useful and relevant off-chain information surrounding the state of Polkadot / Kusama. While the project is online, I don't consider it "finished" as there is still a lot of things to add and enhance on Polk-auction. + +* Project with background processing of files and websocket messaging for communication between multiple applications. + +* Different DDD projects with back-end(s) (HTTP API, written with .NetCore and Entity) and UI app(s) (web-app), multiple databases and mechanisms for back-end communication if/when needed. + +* Multiple other projects and PoC, mostly with backend technologies (Java, C++, C#) + +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. + +### Team Code Repos + +* https://github.com/CrommVardek + +### Team LinkedIn Profiles + +* https://www.linkedin.com/in/cyril-carlier/ + +## Development Status :open_book: + +As mentioned, this application is a response from the [anti-collusion infrastructure RFP](https://github.com/w3f/Grants-Program/blob/master/rfps/open/anti-collusion_infrastructure.md) + +## Development Roadmap :nut_and_bolt: + + +### Overview + +- **Total Estimated Duration:** 15 months +- **Full-Time Equivalent (FTE):** 0.15 FTE +- **Total Costs:** $9,000 + +### Milestone 1 — Implement Voter functions + +- **Estimated duration:** 9 months +- **FTE:** 0.1 FTE +- **Costs:** 3,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can deploy the contract and use its functions. References, such as the MACI research page or the specs of MACI implementation, will be provided. | +| 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. | +| 1. | Maki: constructor and internal state | Contract internal state needed to work properly and its constructor | +| 2. | Maki: signUp function | User function to register for the vote (ink!) | +| 3. | Maki: publishMessage function | User function to vote (ink!) | +| 4. | Maki: processMessage function | Coordinator function to proves that the messages have been correctly processed | + +Note: 0d. not included, because it would be overkill to setup a whole environment on a docker image just to deploy the contract while other resources already exist for that. + +Note: As the implementation is based on others work (research and specification), we will give credits and link the needed parts of it. + +### Milestone 2 — Coordinator's functions + +- **Estimated Duration:** 6 months +- **FTE:** 0.3 FTE +- **Costs:** 6,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can deploy the contract and use its functions. References, such as the MACI research page or the specs of MACI implementation, will be provided. | +| 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. | +| 0e. | Article | We will publish a Medium **article** and the same article on SubSocial to explain what is Maki. The articles will be referenced on Reddit (/r/Kusama and /r/Polkadot) and on diverse Discord Server related to Polkadot (mostly the important and official ones). +| 1. | Maki: proveVoteTally function | Coordinator function to prove the result of the vote tally on-chain (ink!) | +| 2. | Maki: verifyVoteTally function | Function to verify the result of the vote tally and the proof of it (ink!) | +| 3. | Circuits | Circuit used to generate the zk-Snark (in TypeScript and Circom) - this will be based (if not reused) on this work [MACI](https://github.com/privacy-scaling-explorations/maci/tree/master/circuits/ts) and [MACI](https://github.com/privacy-scaling-explorations/maci/tree/master/circuits/circom). One circuit for proveStateCorrectness and one for proveVoteTallyCorrectness functions. | +| 4. | Votes Verifier | Verifier contract/function (in Rust/ink!) to verify that the proof is correct - this will be based on this work [MACI](https://github.com/privacy-scaling-explorations/maci/tree/master/circuits/ts). The verifier will be used by Maki| + +Note: 0d. not included, because it would be overkill to setup a whole environment on a docker image just to deploy the contract while other resources already exist for that. + +Note: As the implementation is based on others work (research and specification), we will give credits and link the needed parts of it. + +## Future Plans + +I plan to deploy this contract on one of the parachain (for example on Shiden) of Kusama to ask the community what would be their preferred choice for the next development/feature/changes of Maki. + +Which led us to the long-term plan... That would be: +- Add a simple UI/library (in Typescript) to interact with the contract easily. +Please include here. +- Provide different circuits for the proof +- Provide a way to configure the contract to allow non-quadratic votes, or for example conviction votes + +These are just ideas. I would also like for the community (developers) to participate, re-use, enhance or create their own version of Maki. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +I've been part of the program once ([polk-auction application](https://github.com/w3f/Grants-Program/blob/2606f01f2fed14bb358560c8ececc9ad05e40bb8/applications/polk-auction.md)) diff --git a/applications/MangoBOX-Protocol.md b/applications/MangoBOX-Protocol.md index 2e8bad12479..566eee39af4 100644 --- a/applications/MangoBOX-Protocol.md +++ b/applications/MangoBOX-Protocol.md @@ -1,8 +1,5 @@ -# W3F Grant Proposal +# MangoBOX Protocol - - -- **Project Name:** MangoBOX Protocol - **Team Name:** MangoBOX labs - **Payment Address:** 0x33e69715988126eB3653bFAfd338320BE9A10cd0(USDC)) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/MangoSale_Protocol.md b/applications/MangoSale_Protocol.md new file mode 100644 index 00000000000..c502002abdf --- /dev/null +++ b/applications/MangoSale_Protocol.md @@ -0,0 +1,391 @@ +# MangoSale Protocol + +- **Team Name:** MangoBOX labs +- **Payment Address:** 0x33e69715988126eB3653bFAfd338320BE9A10cd0(USDC)) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + + +## Project Overview :page_facing_up: + +https://github.com/w3f/Grant-Milestone-Delivery/pull/612 + +Through the joint efforts of all team members, we have completed the development and submission of the first grant and also furthered our understanding of Polkadot ecology and the entire industry. + +MangoBOX labs is committed to the development of the DAO fundraising system, in the hope of developing a complete fundraising system. In the first stage, we developed an Ink! version smart contract of MangoBOX protocol based on *Juicebox* , which is a well-known project on Ethereum. + +However, in the actual process of development, we found some shortcomings of the Juicebox protocol as well : tokens can be issued additionally without restrain, the fundraising rounds are difficult to manage, and overall the protocol is relatively complicated to use. These characteristics are not conducive to the large-scale application of a Web3 product. + +After multiple rounds of research by our product team, we decided to conduct a more in-depth exploration in the field of DAO fundraising. We specialized in Ink! Smart contract version of MangoSale Protocol. MangoSale Protocol is a license-free protocol designated for project fair launch, which is considered as an open IDO platform. It is not limited to DAOs, but also applicable to various types of individuals or organizations. Compared to Juicebox, it's simpler and fairer to use. Any project party can raise the funds they want in different ways through the MangoSale Protocol. + + + +### Overview + +- **If the name of your project is not descriptive, a tag line (one sentence summary).** + +MangoSale Protocol is based on Ink! A protocol developed by smart contracts that does not require permission and is used for the fair launch of projects belongs to an open IDO platform. Anyone, any community, and any organization can initiate token auctions and financing without permission, and carry out fair distribution of tokens. + +Based on Ink! version smart contracts, MangoSale Protocol is a permissionless , project fair launch oriented protocol that acts as an open IDO platform. Any individual, community or organization can start token auctions and financing without permission and implement token fair distribution. + + + + Well-known IDO platforms for inspiring MangoSale Protocol as below : + +​ 1. Pinksale： https://www.pinksale.finance/ + +​ 2. Unicrypt: https://unicrypt.network/ + +​ 3. Gempad: https://gempad.app/ + + + + +- **A brief description of your project.** + + + + As a permissionless fair distribution protocol, MangoSale Protocol is an open IDO platform which has the main following functions and features: + + + + - Permissionless and decentralized. Anyone can start the creation and auction of Token through the MangoSale Protocol and raise funds without any threshold or code base. + + - Multi-chain deployment. MangoSale Protocol will be deployed on multiple Ink! smart contracts supported para-chains in the future. The para-chain project owners can also deploy projects on their own. + + - Coexistence of multiple Web3 tools. MangoSale Protocol will provide at least three Web3 tools: + + 1. MangoToken, Token factory can create Tokens with tax function. + + 2. The MangoLock time lock function can lock up tokens in periods to realize the linear release of tokens. + + 3. MangoAirdrop system. The airdrop system project owner can initiate airdrops for different users, which is conducive to expanding the group of currency holders. + + + + - Coexistence of multiple auction methods. MangoSale Protocol will support three different types of auctions to facilitate the launch of various natured projects, and the project initiators can choose freely according to their actual situation + + 1. Launchpad: Token auction by a fixed price. + + 2. Fair Launch: Token auction in the form of fair launch. + + 3. Dutch Auction： Token auction in the form of Dutch Auction. + + + +- **An indication of why your team is interested in creating this project.** + + + +At present, there are more and more projects starting and financing in the encrypted world, and there also exist IDO platforms that provide services for various crypto projects. However, many IDO platforms are required to get permit, official review and KYC verifications from official authorities. This greatly hinders the scale of project initiation and sets various preconditions for the initiation of the project, making the process of project initiation tedious and difficult. + +In this context, MangoSale Protocol launched a permissionless IDO fair launch platform. Any individual, community or organization can start Token auctions and financing without permission and implement token fair distribution. + +At the same time, all smart contracts of MangoSale Protocol have been designed in advance. Anyone without code knowledge can complete the issuance and financing of tokens through a fixed template, which greatly simplifies the start-up process and enables all various projects to be completed as soon as possible. + + + +- **An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama.** + +With its continuous expansion and especially the steady progress of parachain auctions, the Polkadot ecosystem has entered a new stage. It no longer only focuses on the construction of the underlying technology, but also has entered the stage of ecological construction in an all-round way. At this time, various types of project owners are required to develop on different parachains. This is also an important reason why we are now developing MangoSale Protocol. + +We hope to develop a permissionless project launch and fundraising platform for the overall ecology of Substrate / Polkadot / Kusama, so that all types of projects in different stages can start on their own with the minimal costs and simplest steps and finally raise appropriate funds. This is our hope and vision today. + + + +### Project Details + + + +- **Documents of the main functions possessed by the MangoSale Protocol** + +1. MangoTokenFactory: TokenFactory can not only create standard ERC20 tokens, but also create ERC20 tokens with special functions, i.e, ERC20 tokens with tax functions. Taxation can be divided into different modules, such as marketing wallet and repurchase burning. Project owners can initialize the token factory according to their actual needs. + +2. MangoLock: The time lock function is also one of the core functions of the startup project. Through time lock, tokens can be locked in periods to implement the linear release of tokens, which can fully gain the trust of the community and make the project Token issuance mechanism more transparent. + +3. MangoAirdrop system: Project initiators can use the airdrop system to launch airdrops for different users in the ecosystem to motivate ecosystem contributors, which will help expand the number of coin holders and benefit more community members; + +4. launchpad: Launchpad: Launchpad auctions Token at a fixed price, which is one of the most common auction methods. Launchpad has a soft cap and a hard cap. If the soft cap is not reached, the auction will be cancelled. If the soft cap is reached, the auction will be successful. The maximum fundraising amount is the hard cap value. Token auction price is calculated according to the price set in advance, and the exchange rate is fixed. + +5. Fair Launch: Token auctions are conducted in the form of Fair Launch, and the auction price is not fixed. Fair Launch has only a soft cap, and there is no cap on the amount of funds raised. At the same time, the Token auction is not carried out according to a fixed exchange rate but according to the total amount of funds raised at the end of the auction. If the amount of funds raised reaches the soft cap and the fundraising is successful, the total amount of funds raised divided by the total number of tokens provided will be the user's actual purchase exchange rate. The higher the overall funds raised, the higher the user's purchase exchange rate will be. + +6. Dutch Auction: Token auctions are conducted in the form of Dutch auction. Dutch auction is a special auction method, also known as "reduced price auction". It refers to an auction in which the bids for the auction target decrease in order from high to low until the first bidder answers (reaches or exceeds the reserve price). Choosing such an auction method can make the auction fairer. + + + +- **MangoSale Protocol Functional Model Architecture Diagram** + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/structuraldiagram.png) + + + +- **Mockups/designs of any UI components** + + + +1.**MangoTokenFactory:** + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-creattoken.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/creattoken-admin.png) + + + +2.**MangoLock: ** + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-createlock.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/locklist-viewlptoken.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/locklist-viewtoken.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-locklist.png) + + + +3.**MangoAirdrop system:** + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-airdrop.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-airdroplist.png) + + + +4.**launchpad: ** + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-launchpad.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/launchpad-next.png) + + + +5.**Fair Launch: ** + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-fairlaunchpad.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/fairlaunchpad-next.png) + + + +6.**Dutch Auction: ** + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/mangosale-dutchauction.png) + + + +![](https://raw.githubusercontent.com/Mangoboxlabs/MangoSale/main/pic/dutchauction-next.png) + + +- **Technology Stack** + - JavaScript – the world's most popular programming language. + - [Vue](https://vuejs.org/index.html/) – An approachable, performant and versatile framework for building web user interfaces. + + - [PolkaApi](https://github.com/polkadot-js/api) – This library provides a clean wrapper around all the methods exposed by a Polkadot/Substrate network client and defines all the types exposed by a node . + + - [ink!](https://github.com/paritytech/ink) – ink! is an eDSL to write smart contracts in Rust for blockchains built on the Substrate framework. ink! contracts are compiled to WebAssembly. + + - [cargo-contract](https://github.com/paritytech/cargo-contract) ‒ CLI tool for ink! contracts. + - [Contracts UI](https://paritytech.github.io/contracts-ui/) ‒ Frontend for contract instantiation and interaction. + - [Substrate Contracts Node](https://github.com/paritytech/substrate-contracts-node) ‒ Simple Substrate blockchain which includes smart contract functionality. + + + +### Ecosystem Fit + + + +- **Where and how does your project fit into the ecosystem?** + +Under the leadership of Web3 and Parity team, after five years of development, the Polkadot ecosystem has entered a formal auction era for parachains, and more and more parachains have entered the operational stage, making Polkadot ecosystem flourish. Meanwhile, it has also entered into a new stage of development which is in great demand for applications on every para-chain to make the whole ecosystem truly prosper and create a Web3 world. + +In the world of web3, decentralized governance and transparent fund management are the most basic requirements of ecology, which are also the requirements for every ecological participant. We hope that when MangoSale Protocol is fully created, it can serve various participants in the Polkadot ecosystem and provide a complete set of treasury management solutions. + +- **Who is your target audience?** + +MangoSale Protocol can create and auction Tokens for different types of combinations and individuals without permission, and finally realize the fundraising. + +- **What need(s) does your project meet?** + +Whether it's for a project provider or a DAO organization, it is a complex and tedious process to create a treasury and issue tokens to community members and raise funds. The vast majority of the projects failed due to the lack of technical capabilities. MangoSale system allows teams to configure and manage the whole fund-raising process with no need for coding, tackling the complexity of fund-raising from the community by the project providers. + +- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** + +In the Substrate/Polkadot/Kusama ecosystem, we have not found any similar product. But there are some project in DAO's frame, such as subDAO and Dorafactory, that can provide some certain DAO infrastructure products and create all types of DAOs. + +​ More similar projects in Ethereum and BNB ecosystems: + +1. Pinksale： https://www.pinksale.finance/ +2. Unicrypt: https://unicrypt.network/ +3. Gempad: https://gempad.app/ + + + +## Team :busts_in_silhouette: + +### Team members + +- **Jason Zhao**: Team leader, project architect, PM and technical leader. He has over 15 years of experience in Internet technology as a senior developer. He began to know Bitcoin in 2015 and gradually emerged himself in the R&D of blockchain technology. He started to notice Polkadot in 2021 and decided to focus on the development of the Polkadot ecosystem. +- **Frank Yu:** Full stack IT developer, 10 years of experience in IT, in command of programming languages such as PHP,Java, C++. Looked into the study and development of Ethereum in 2018; Committed to the Polkadot ecosystem in 2021. +- **Owen Hu:** Full stack developer, smart contract engineer, 8 years of experience in IT development, currently focuses on the R&D of the blockchain technology in Web3. +- **Kevin Luo:** Full stack developer, front-end engineer, 6 years of IT experience, currently focuses on the R&D of the blockchain technology. +- **Alex Li:** Senior designer , 10 years of experience in Internet design, maintains a high standard of design and art. + +### Contact + +- **Contact Name:** Jason Zhao +- **Contact Email:** MangoBOXLabs@gmail.com +- **Website: mangobox.xyz** + +### Legal Structure + +- We are preparing to register a legal entity in Hong Kong. + +### Team's experience + +We are a Web3 start-up team from Beijing, China with Jason Zhao as our team leader and technical leader. Our team members come from different fields, from architects, product managers to full stack developers. Although we do not have a rich experience in Web3, our team has never been short of strong execution and high technical development capabilities. Our endless enthusiasm for Web3 led us to the start-up wave. As traditional Web2 practioners, our team has been engaged in the IT development in China for the last decade. As soon as Web3 opened a window to a brand new world, we immediately seized the opportunity. + +We found that the crypto industry holds endless opportunities like no other industry can match. The core vision of crypto and Web3 is to provide everyone with a native and open-source digital economy. Web3 is structured on the basis of blockchain, smart contracts and oracles, which holds a great potential to build a brand new and open ecology. + +Our team has been devoted to the R&D on the Ethereum ecosystem and not until 2021 when the Polkadot para-chains began to be deployed and applied that we had a better understanding of the ideas, principles and technology of the Polkadot ecosystem. We realized that whether it's from the top-tier ideas or the bottom technical structure, Polkadot represents the future and that's why we decided to commit to the build-up of the Polkadot ecosystem. Now as all para-chain on Polkadot are being operational, there is an emerging demand for DAPP's deployment and bulid-up, which is our unprecedented opportunity. + + + +### Team Code Repos + +- https://github.com/Mangoboxlabs + +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/Jasonweb3 + +- https://github.com/luckelf + +- https://github.com/Kevinluoo + + + +### Team LinkedIn Profiles (if available) + +- none available + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 4 FTE +- **Total Costs:** 26000 USD + +### Milestone 1 — Ink! contract Modules + +- **Estimated duration:** 1 month +- **FTE:** 4 +- **Costs:** 12,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------------------------- | ------------------------------------------------------------ | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide a basic **tutorial** that explains how a user can deploy and test our Ink! contract. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article** that explains how to use our product. | +| 1. |Ink! Contract:TokenFactory | TokenFactory can create ERC20 tokens with tax functions. | +| 2. |Ink! Contract: MangoLock | MangoLock can realize the lock-up and linear release of Token.. | +| 3. |Ink! Contract: MangoAirdrop | MangoAirdrop can implement different types of token airdrops. | +| 4. | Front-end UI | We currently use the Vue.js framework for Front-end development . In the first milestone we will develop the front-end UI of these three parts: TokenFactory, MangoLock and MangoAirdrop.We will provide Front-end deployment tutorials for TokenFactory、 MangoLock and MangoAirdrop . | +| 5. | Front-end integration (e2e) test | We will use Cypress.io as an end-to-end testing framework for the Front-end automated approach test. | + + + +### Milestone 2 — Ink! contract Modules and Frontend files + +- **Estimated Duration:** 1 month +- **FTE:** 4 +- **Costs:** 14,000 USD + + +| Number | Deliverable | Specification | +| -----: | ------------------- | ------------------------------------------------------------ | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide a basic **tutorial** that explains how a user can deploy and test our Ink! contract. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article** that explains how to use our product. | +| 1. | Ink! Contract: launchpad | Launchpad can conduct Token auctions at a fixed price. | +| 2. | Ink! Contract: Fair Launch | Fair Launch can conduct Token auctions in the form of fair launch. | +| 3. | Ink! Contract: Dutch Auction | Dutch Auction can conduct Token auctions in the form of Dutch auctions. | +| 4. | Front-end UI | We currently use the Vue.js framework for Front-end development . In the second milestone we will develop the front-end UI of these three parts: launchpad Auction、 Fair Launch Auction and Dutch Auction. We will provide Front-end deployment tutorials for launchpad Auction 、 FairLaunch Auction and Dutch Auction. | +| 5. | Front-end integration (e2e) test | We will use Cypress.io as an end-to-end testing framework for the Front-end automated approach test. | + + +**Introduction to the three auction functions:** + +1. launchpad Auction:Launchpad auctions Token at a fixed price, which is one of the most common auction methods. Launchpad has a soft cap and a hard cap. If the soft cap is not reached, the auction will be cancelled. If the soft cap is reached, the auction will be successful. The maximum fundraising amount is the hard cap value. Token auction price is calculated according to the price set in advance, and the exchange rate is fixed. + +2. FairLaunch Auction: Token auctions are conducted in the form of Fair Launch, and the auction price is not fixed. Fair Launch has only a soft cap, and there is no cap on the amount of funds raised. At the same time, the Token auction is not carried out according to a fixed exchange rate but according to the total amount of funds raised at the end of the auction. If the amount of funds raised reaches the soft cap and the fundraising is successful, the total amount of funds raised divided by the total number of tokens provided will be the user's actual purchase exchange rate. The higher the overall funds raised, the higher the user's purchase exchange rate will be. + +3. Dutch Auction: Token auctions are conducted in the form of Dutch auction. Dutch auction is a special auction method, also known as "reduced price auction". It refers to an auction in which the bids for the auction target decrease in order from high to low until the first bidder answers (reaches or exceeds the reserve price). Choosing such an auction method can make the auction fairer. + + + + + +## Future Plans + +- **how you intend to use, enhance, promote and support your project in the short term, and** + +We first hope to develop the smart contract of the product. It will then proceed to deploy on a parachain for initial testing. + +- **the team's long-term plans and intentions in relation to it.** + +When our product starts testing, we hope to build our global community based on the Polkadot ecosystem, and start to incubate many organizations to start raising funds through our platform. + + + +## Additional Information :heavy_plus_sign: + +- **How did you hear about the Grants Program?** + +Web3 Foundation Website. + + +- **Work you have already done.** + +We have deeply researched the function and logic , and we hope to use ink! Smart contracts refactor it. + +- **If there are any other teams who have already contributed (financially) to the project.** + +NO. + +- **Previous grants you may have applied for.** + +NO. + diff --git a/applications/MeProtocol.md b/applications/MeProtocol.md new file mode 100644 index 00000000000..f702adaa384 --- /dev/null +++ b/applications/MeProtocol.md @@ -0,0 +1,265 @@ +# Me Protocol + +- **Team Name:** My AI +- **Payment Address:** Fiat 05.02.2024, 10:41 (CET) +- **Level:** 2 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1340#issuecomment-2583612024) + +## Project Overview :page_facing_up: + +### Overview + +**What is the Me Protocol?** + The Me Protocol is a purpose-built exchange infrastructure for blockchain-based rewards. It provides the fundamental technology for the creation of a frictionless, limitless, and decentralised rewards ecosystem for all companies, large or small, to participate. + +**Background:** + +**Loyalty rewards are moving to a blockchain near you.** +Wouldn’t it be great if you could buy a coffee with unused airline miles? Or if your rewards never expired, and you could trade them? Whether it’s sports teams, airlines, hotels, Highstreet fashion or your local pizzeria, brands from almost every sector are looking to take advantage of what blockchain technology can do to transform the **$180b in global loyalty rewards by allowing rewards to be exchanged and redeemed across brands.** + +**Blockchain-based rewards are great for consumers, but also for brands:** +1. Customers not using rewards are **3x more likely to defect from a brand.** +2. While brands try their best to provide attractive offers, **less than half of rewards are actually used.** This is **$90b of value left on the table.** +3. Rewards on a blockchain can be more easily exchanged than traditional points, meaning **when a current customer cannot immediately use their rewards, they can exchange them with someone who can.** +4. This means **existing customers are happy and new customers are acquired** – unachievable with traditional loyalty programs. + +**Making blockchain-based rewards work in practice however requires solving two general problems:** +- **Accessibility** – Simply creating a reward token that can be exchanged doesn’t mean that it will be exchanged. + 1. Where do you go to redeem the rewards? + 2. How do you exchange them? + 3. Most consumers will not bother to search for loyalty redemption options, then go find a DEX, then a peer and then calculate what they need to swap to get the rewards they need. + + **Solution** – We are building a dedicated **‘reverse’ marketplace** for blockchain-based loyalty rewards. Simplified redemption, for everyone, from every brand, with the exchange complexity hidden in the background. + + - **Liquidity** – Just because a brand wants to release reward tokens, doesn’t mean they can be easily exchanged in a marketplace. + 1. What is the value of these reward tokens? + 2. How do we ensure that the exchange brings benefits to the brand as well? + 3. How do we balance inflow and outflow and drive new customers to brands? + 4. What do we do about tokens on different blockchains? + + **Solution: The Me Protocol.** Specifically designed to power the emerging brand economy by facilitating the exchange of brand loyalty rewards. + +**Why are we motivated to build in the Substrate/Polkadot/Kusama ecosystem?** +We like the ecosystem for several reasons: + +- We share the same philosophy of interoperability. +- Our exchange functionality utilizes the concept of decentralized exchanges but engineered for loyalty rewards, leveraging Polkadot's ecosystem for cross-chain operations. +- As we continue to develop our protocol, it should integrate with other related protocols and be used by other applications without being constrained to one network. + + +## Project Details + +![Polkadot ecosystem](https://user-images.githubusercontent.com/52800276/205578388-a180149c-19f1-4bf2-8333-4f8911a7c986.png) + +### Technologies: + 1. Ink! and RUST (smart contracts), + 2. OpenBrush (smart contract library) + 3. Substrate (smart contract) + 4. Polkadot.js (back end and frontend integration with smart contract) + 5. TypeSript (front end and backend scripts) + 6. NestJs and Reactjs (backend and front end framework) + 7. PostgreSQL with Typeorm (database and connection) + 8. Elastic Search and Redis Cache (searching and indexing) + 9. Fastify Multipart (image management), + 10. Winston (logging) + 11. Docker (containerization) + 12. Nestjs testing and jest (testing) e.t.c + +### Architectural Summary + +newmearchitecture + +Our solution has two major components: the Me App and the Me protocol. + +**The Me App** contains all the necessary interfaces, services, microservices and infrastructure that allows consumers (individual users) to sync/manage/connect their loyalty rewards and interact with offers pushed to them from the various brands and businesses on our platforms that issued those rewards. These users can redeem their rewards for offers in the marketplace. The Me App also handles all the logic for managing brand accounts, allowing them to push offers to their customers and providing them with analytics on the performance of their rewards programs and offers in our ecosystem. + +**The Me Protocol** contains all the contracts, libraries and abstract contracts used to manage tokenized brand rewards, swap them and route them to appropriate wallets. It also contains the various utilities for managing pools such as the brand fee pool, brand treasury pool, and brand bounty pool. + +For a start, the protocol would simply be a set of smart contracts containing all the necessary business and operational logic, but eventually it would evolve into a parachain to further serve the peculiarities and nuances of the loyalty reward space. + +The design of the protocol follows the EIP-2535 pattern originally proposed by nick mudge. + +Screenshot 2022-12-06 at 15 39 56 + +There is a main contract which houses the utility storage for the protocol and some function selectors via which it can route to other contracts called facets, containing the business logic to be executed. The routing is done via delegatecall. + +While other facets serve one business logic or another, the upgrader and loupe help to manage upgrades (following governance decisions) and introspection into the protocol respectively + + + +### Ecosystem Fit + +**Where do we fit in the Web3 ecosystem?** +In as much as we can generalize, our project fits somewhere in the middle of Social (shareable rewards), DeFi/Exchange (rewards economy), Identity (allowing users to own the data keys to their loyalty) spaces. If you consider ‘ecommerce’ a sector, then we are definitely there (decentralized commerce). + + **Target Audience** +We hope the project attracts dapp and other developers to build integrations and participate in the further development of the protocol. +- The protocol will integrate with our marketplace so the target audience for that includes everyday consumers and brands/businesses seeking to transition to blockchain-based loyalty programs + +- Web3-based projects with utility/reward tokens, social protocols, etc. that want to increase the value of their rewards. + +**Needs that we meet** +In addition to those covered in the above sections: +- Web3-based applications with utility tokens/rewards are in need of a way to extend out the value of these rewards beyond saying they are listed on an exchange or that they can be used for gas and a few other redemption options. Our protocol and the apps built around it will provide unlimited redemption options, thus increasing reward value for innumerable Web3 projects. + +- Example: social protocols, leveraging blockchain to facilitate human interaction, can also leverage the Me protocol to boost engagement and provide real value to current and prospective users. + + **Similar projects in the Substrate / Polkadot / Kusama ecosystem?** +A similar project on the DEFI side is Stellaswap (https://stellaswap.com/) and on the loyalty program side is Project Venkmann https://www.venkmanholdings.com/ + + **How are we different?** + - Me Protocol is different from Stellaswap because we are not a typical DEX, we just use the concepts of decentralized exchanges to power our multi-vendor loyalty program and to enable the swapping of loyalty rewards across brands. Consumers of these rewards would hardly know that there is a swap, all they know is that they can spend the same reward across multiple brands. + +- Me Protocol is also different from project Venkmann because we do not set out as a loyalty program manager for brands, rather we are the interoperator of loyalty programs, providing one blockchain protocol that brands and even loyalty program managers can integrate to enable a multivendor loyalty ecosystem where rewards can be moved seamlessly across brands with no overhead. + + +## Team :busts_in_silhouette: + +### Team members + + **Name of team leader** + Robert Wesley (CEO) + + **Names of team members:** + - Robert Wesley (CEO) + - Paul Oamen (CTO) + - Pius Onobhayedo + - John Chimaobi + - Ayomide Adebara + - Boluwatife Oguntoyinbo + - Nwele Uchenna + + We will be hiring an additional Rust/Ink! developer + +### Contact + +**Contact Name:** Robert Wesley +**Contact Email:** wesley@meprotocol.io +**Website:** https://meprotocol.io + +### Legal Structure + +- **Registered Address:** My AI Inc. 251 Little Falls Drive, Wilmington, New Castle County, Delaware 19808 USA (registered address); 8 The Green Suite 11901 Dover, DE 19901 (business address) + +- **Registered Legal Entity:** My AI Inc. (Delaware C Corp) + +### Team's experience + +We have founded and co-founded several tech companies (e.g. Kivu Technologies, Cognitive Architectures, Useful Technologies) and worked on a variety of complex software development projects spanning graph computing to blockchain based solutions. + +- **Robert Wesley (CEO)** is an international serial entrepreneur. Having founded five organisations across sectors and continents, Robert's diversity of entrepreneurial experiences spans from graph computing to blockchain to AI. Founder @ Sender Ventures; Founder @ KIVU Technologies; Co-Founder @ Cognitive Architectures; International Diplomat @ UN; MBA @ESADE + +- **Paul Oamen (CTO)** is one of Nigeria's rising Web3 stars, where in addition to venture building, set up and served as the principal instructor at the Pan Atlantic University's Blockchain Programme and is a core contributor to the zone blockchain, Africa's layer-1 Blockchain network for digital payments in fiat and regulated digital currencies. Co-Founder @ Usefull Technologies; Blockchain Instructor @ Pan-Atlantic University, Lagos Business School; + +- **Dr. Pius Onobhayedo** is the Head of the Computer and Information Sciences Department at the Pan-Atlantic University. Aside from building an entire university department, Dr. Onobhayedo’s distinguished career has also included appointments at the University of Southern California in the United States and the University of Navarra in Spain. He has also served as CTO of multiple software companies. + + + + +### Team Code Repos + +- https://github.com/Me-Protocol + + +GitHub accounts of team members + +- https://github.com/AgentPoles +- https://github.com/developeruche +- https://github.com/codemobii +- https://github.com/piosystems +- https://github.com/Teepheh-Git +- https://github.com/Adebara123 + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/robert-wesley/ +- https://www.linkedin.com/in/paule-oamen/ +- https://www.linkedin.com/in/piusono/ + + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 5 months +- **Full-Time Equivalent (FTE):** 2600 hrs +- **Total Costs:** 29600 USD + +### Milestone 1 — Implement the Core Parts of the Protocol + +- **Estimated duration:** 1 month +- **FTE:** 800hrs (5 persons) +- **Costs:** 12,500 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user, brand or third party application can interact with our protocol for the various specified use cases | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish a **lite paper** to describe the architecture and its implementation +| 1. |Build out the Pool Component| We will implement the Rewards Pool Component which contains the contracts, libraries and interfaces that describe and manage the sets of AMM pools for brand loyalty rewards. This component primarily consists of the pool contract, which manages all the logic relating to brand liquidity (swapping, adding, removing, multistage swapping, etc.), and the Pool initiator contract, which would create a pool every time a new brand reward is to be supported on our protocol. These are similar in concept to Uniswap Pool and Pool Deployer contracts, but with different requirements/implementation logic and no concentrated liquidity.
          **Languages and framework:** Ink!, Openbrush| +| 2. | Build out the rewards factory component | We will implement the Rewards Factory, which allows brands with or without Web3-based rewards to move some or all of their loyalty points to the blockchain using the PSP22 standard (and also PSP34/PSP1155 in the future). It contains the function for creating a new PSP22 token and keeping track of the associated brand.
          **Languages and framework:** Ink!, Openbrush | +| 3. | Build out the Rewards Periphery Component| We will implement the Rewards Periphery Component that provides a form of incentivization to brands when their rewards are used to redeem offers across other brands. This component consist of two major contracts: Brand Bounty and Brand Treasury Contracts. Brand Treasuries are small fees paid by brand A to brand B when a customer from brand B chooses to redeem his/her reward with brand A. The treasury is a smart contract that holds these tokens, mapped to the appropriate brand. Brand bounties on the other hand are small amounts of reward tokens charged to a customer when he chooses to redeem that reward with another brand (typically swapping in our protocol). These small fees are stored in the Bounty Contract and when a bounty threshold is reached, they are issued as rewards to promote the issuing brand.
          **Languages and framework:** Ink!| +| 4. | Build out the service payment component| We will implement the Service Payment Component that brands and other integrating third-party applications will use to pay for the various services rendered to them through the protocol and business applications. This component consists of the payment/fee contract, which contains the logic to handle the reception of these tokens, mapped to the payer, and the logic to release these tokens when a paid service is rendered to the payer.
          **Languages and framework:** Ink!| +| 5. | Build Out the Rewards Valuation Oracle Component| We will implement the Rewards Valuation Oracle Component, which helps to manage all external requests relating to rewards pricing and valuation in the protocol based on the supply and demand of these rewards in the pool. It consists primarily of the oracle contract that provides information on the valuation of rewards in our protocol.
          **Languages and framework:** Ink!| + + + +### Milestone 2 — Adding the Protocol Peheripherals and Kickstarting the Frontend and Backend services + +- **Estimated Duration:** 2 months +- **FTE:** 900hrs (3 persons) +- **Costs:** 8,550 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user, brand or third party application can interact with our protocol for the various specified use cases | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish a **lite paper** to describe the architecture and its implementation +| 1. |Build out the Protocol Access Component| We will implement the Access Component, which consists of contract routers that abstract the core protocol services and provide functions that brands, customers, protocol admins, and third-party applications can use to safely interact with the protocol. These are similar to the Uniswap router contracts, but instead of just one general contract, the contracts are split into Customer, Brand, Admin, and in the future Third-Party Contracts, based on the role of the requestor. A brand router, for example, will expose the functions that allow a brand to create a reward (using the reward factory), mint additional rewards or burn existing rewards, add or remove rewards from the liquidity pool, top up fee wallet, etc.
          **Languages and framework:** Ink! | +| 2. | Build out the lens component | We will implement the Lens Component that provides introspection into the protocol. This component is comprised of the Secretary and Loupe Modules. The Secretary Contract would provide business information like how many brands are connected to the protocol, total loyalty rewards in pools, etc. The Loupe Contract provides protocol architecture information, such as what functions the protocol supports and where these functions are deployed (it is an implementation of the EIP2535 DiamondLoupe Contract) etc.
          **Languages and framework:** Ink!| +| 3. | Building out the Governance Component | We will implement the Governor Facet that will help to manage access control across the protocol and also help to manage governance rules for future proposals and updates.
          **Languages and framework:** Ink!| +| 4. |Build out the Backend Service Components for the Me App| We will implement some key utilities for the back-end services to be used by integrated apps, such as logging (Winston); data caching (Redis Cache); search indexing (Elastic search); database and connection (Postgres TypeOrm); mailing service (Nestjs nodemailer with sendgrid abi); image upload with (Fastify multipart); and entities and their relationships (Typescript, NestJs, PostgreSQL).| + + + + + + +### Milestone 3 — Rounding Up with the APP MVP and Integrating the Protocol with the APP + +- **Estimated Duration:** 2 months +- **FTE:** 900hrs (3 persons) +- **Costs:** 8,550 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user, brand or third party application can interact with our protocol for the various specified use cases | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish a **lite paper** to describe the architecture and its implementation +| 1. | Build out the Asset Management Component of the Me APP| We will implement all the necessary screens, services and microservices that let brand customers to keep track of, earn and spend rewards in applications and also for brands to keep track of, distribute and manage their rewards in applications.
          **Languages and framework:** TypeScript, Nestjs, Reactjs, Polkadotjs.| +| 2. | Build out the offers management component of the Me APP| We will implement all the necessary screens and provide all the necessary services and microservices that will allow brands to integrate their offers, create new offers and push them to applications and also allow brand customers to search offers, filter offers, view price, see offers whose rewards they have, redeem these offers with their rewards.
          **Languages and framework:** TypeScript, Nestjs, Reactjs, Polkadotjs, PostgreSql| + + + + +## Future Plans + +- We will first incorporate the Me Protocol into our own marketplace. This should provide significant exposure to the project and prove-out its utility for additional projects. Our company, My AI, will be dedicated to supporting the protocol as a core developer during near- and long-term. +We will also be establishing a DAO as we move forward that will provide additional governance of the project as we progressively decentralise. + +- We also plan to offer a significant suite of perks, bounties, rewards etc. to contributors of the project to encourage wider participation during the formative period as well as into the longer term. + +- In the end, the Me Protocol should be an integral component of the emerging ‘brand economy’ as a key piece of infrastructure for meta- and non-metaverse rewards. + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Was recommended that we apply by Daniel Cake-Baly from Parity Technologies. + +**Previous grants:** We received financial support in the form of an investment from the Blockchain Founders Group. diff --git a/applications/Melodot.md b/applications/Melodot.md new file mode 100644 index 00000000000..94403276d42 --- /dev/null +++ b/applications/Melodot.md @@ -0,0 +1,238 @@ +# Melodot: Incentive-compatible data availability layer + +- **Team Name:** ZeroDAO +- **Payment Address:** 0xEBCDa7c73EB5Dd7a4314cFf395bE07EB1E24c046 (DAI) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview 📄 + +#### Data Availability Layer + +The current data availability layer scheme requires the assumption that the network has at least the minimum number of honest nodes.However, due to the need to prevent data retention attacks, the samplers are required to be anonymous, making it difficult to measure the number of samplers. At the same time, samplers are more concerned with data related to themselves, resulting in an uneven distribution of total active samplers over time. The assumption of a minimum number of honest nodes affects the robustness of the data availability layer. + +Challenging issues in the data availability layer also include: who will perform distributed generation, who will reconstruct the data, who will store the data, how long will the data be stored, and how to ensure that these tasks are well done. + +One possible approach is to delegate these tasks to consensus validators, but there is a lack of effective incentive mechanisms. For cost considerations, not performing distributed generation, data reconstruction, and data storage is the most profitable for validators. In addition, consuming too many resources of consensus validators is very unfavorable for scalability. + +Melodot introduces the role of farmers by combining PoSpace, alleviating the system's dependence on the minimum number of honest nodes assumption, and completing an incentive-compatible distributed generation and data storage scheme. Consensus validators now act more like light clients, improving future scalability. You can learn more from this preliminary [whitepaper](https://www.notion.so/zerodao/Melodot-Data-Availability-Layer-Whitepaper-b72b1f3de81c40fc94a56763756ce34a). + +## Project Details + +### Architecture + +#### Erasure Coding and KZG Commitment + +Melodot uses 2D Reed-Solomon for data expansion, providing better sampling efficiency. It generates KZG commitments in the row direction, avoiding fraud proofs, similar to Ethereum's Darksharding. Block headers contain KZG commitments and data locations for different apps, allowing light clients to sample or download only data relevant to themselves. + +#### Farmers + +Farmers receive rewards through PoSpace, which is used to verify that participants have allocated a certain amount of storage space on their devices. The consensus mechanism is achieved through a time-memory trade-off approach, which has its origins in the [Beyond Hellman](https://www.semanticscholar.org/paper/Beyond-Hellman's-Time-Memory-Trade-Offs-with-to-of-Abusalah-Alwen/39e70d67eeb5ce140171f6d0629daec3b54d74f3) paper and has been adopted for use in the [Chia protocol](https://docs.chia.net/proof-of-space/). This method allows for a more efficient and secure consensus process compared to traditional energy-intensive mechanisms such as Proof of Work. [Subspace improves PoSpace](https://github.com/subspace/consensus-v2-research-paper) for storing "useful data" and is closely linked to KZG commitments. We are inspired by them, in contrast, Melodot's farmers receive rewards through PoSpace rather than reaching consensus. This incentive mechanism ensures that the network can still recover data when natural sampling samples are insufficient and guarantees data storage for at least a specific duration. + +Farmers need to complete the distributed generation of specified data, expanding the data generated by block proposers in the column direction. They then calculate the challenge eligibility through the generated data, similar to [Chia's filter](https://docs.chia.net/signage-and-infusion-points/), with only a small portion of farmers eligible to further search for solutions. This design reduces the computation load on farmers, avoids missing the submission of solutions, and allows farmers to devote more bandwidth and capacity resources to data availability sampling and storage. In addition, farmers are more inclined to generate all specified data in a distributed manner, as each chunk represents a potential lottery ticket. + +Farmers use the committed space to store blob data and maintain its timeliness. New data receives more rewards, while expired data will not be rewarded. Upon obtaining challenge eligibility, farmers need to search for solutions in the stored data, including chunk, data proofs, space proofs, etc. The system adjusts the difficulty based on the reward claims situation. Ultimately, the rewards farmers receive are linearly related to the size of the stored data space and depend on whether they have correctly and promptly completed distributed generation and necessary data reconstruction. + +#### Lifecycle + +![Untitled](https://pic.tom24h.com/zerodao/life.png) + +A complete blob transaction includes: + +- Publishing a blob transaction, including the original KZG commitment +- Block builders collect blob transactions and build blocks, erasure code data, and generate new commitments to be added to the block header +- Consensus validators verify block validity and, along with farmers, perform preliminary availability sampling (not ensuring 100% validity, but with high probability of being valid), either rejecting or accepting the block +- Farmers use the block data, commitments, and proofs learned in the previous step to generate specified columns in a distributed manner +- When the block is finalized + - Farmers with challenge eligibility complete solutions and claim rewards + - Light clients and consensus validators perform sampling simultaneously + - Farmers obtain more specified data from the network for storage and delete expired data + +Melodot is developed in phases, with the first phase not implementing the complete process. + +### Components + +In this phase, we will implement the following core components: + +1. **Erasure-Coding** + + A core module for erasure coding and KZG based on [rust-kzg](https://github.com/sifraitech/rust-kzg), including expanding data and generating commitments and proofs, verifying blob, batch verifying blobs, recovering data, verifying the correct expansion of 2D commitments, and expanding column data and witnesses. + +2. **Melo-Store** + + Interfaces for registering and managing applications, uploading data, and storing data validity data. + +3. **Consensus-related extensions** + +**`excutive_das`** pallet: An extension of the **`frame-excutive`** pallet for scheduling block execution and validation related to DAS + +**`system_das`** pallet: An extension of the **`frame-system`** pallet, adding new block header generation, actual data generation, and validation. + +4. **Sampling Core** + +The core crate that actually performs sampling, which several clients in the system depend on. This includes data availability sampling, obtaining and propagating data from the DHT network, and managing data through rocksdb. + +5. **Light Client** + +A light client that connects to the network and performs sampling based on the block state, including network implementation, distributed generation, data storage, and actual sampling. + +6. **`Melo-PoSpace`** + +A pallet for assigning distributed generation columns to farmers, verifying farmers' challenge chunk, and issuing rewards. + +7. **Farmer Client** + +Connects to the network, obtains raw data, and performs distributed generation; obtains challenges from the chain and searches for solutions to claim rewards. + +### **Non-Goals** + +The goal of the first phase is to minimally implement a usable system and will not fully implement the details described in the whitepaper. The main differences are: + +**PoSpace** + +In the first phase, we will only implement a preliminary version of PoSpace, not including the complete PoSpace process. [Subspace has done an excellent exploration in this regard](https://subspacelabs.notion.site/Subspace-Dilithium-Consensus-Specification-v2-3-274a730b53eb4c93a8d879b90de532ce). In the next phase of development, we should be able to reuse much of their work. + +**Complete Distributed Generation** + +This phase does not include complete distributed generation. Users still need to submit actual data transactions, so farmers and validators do not need to perform the first phase of sampling. + +## **Ecosystem Fit** + +### Similar Projects + +There are currently several data availability layer projects, including Ethereum Danksharding, Celestia, Avail, and Eigen DA. Our main difference from them is the introduction of farmers, which solves many tricky problems faced by the data availability layer. Unlike Danksharding, we decouple an independent data availability layer, which is the same principle as Polkadot not supporting smart contracts. Celestia uses a Merkle encoding pattern, requiring fraud proofs and additional assumptions, which we avoid. Avail's data layout uses a 1.5D scheme, which is unacceptable in terms of sampling efficiency, as detailed in the Melodot white paper. Eigen DA is an Ethereum re-collateralization layer implementation of a data availability scheme, with limited public information available, [but it should be in the form of a DA committee](https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879), which has its applicable scenarios, but is not the same as Melodot. + +### **Relationship with Polkadot and substrate** + +1. With Melodot as a data availability layer, any parallel chain can easily become a Rollup settlement layer. Polkadot brings more secure interactions between settlement layers, significantly increasing Polkadot's capacity. +2. Other teams can develop their own data availability layers based on Melodot. + +## Team 👥 + +### Team members + +- Daqin Lee +- Zhidong Chen +- Sober Man + +### Contact + +- **Contact Name:** Daqin Lee +- **Contact Email:** [lee@melodot.io](mailto:lee@melodot.io) + +### Team's experience + +Daqin Lee: Full-stack Developer, Rust and Substrate Developer, core developer of Melodot. + +Chen Zhidong: Full-stack Developer, Tesla Machine Learning Engineer, [GoHack 2017](http://gohack2017.golangfoundation.org/) Hackathon [First Prize](https://github.com/sillydong/lbsengine), will serve as a technical advisor for Melodot. + +Sober Man: Embedded Engineer, with years of backend and embedded development experience. + +### Team Code Repos + +- https://github.com/ZeroDAO +- https://github.com/DarkingLee +- https://github.com/sillydong + +### Development Status + +ZeroDAO previously developed the Ourspace project, which is a reputation system utilizing social relationships and received support from W3F. After that, we shifted our focus to calculating all social networks in Web3. In this process, we found that they were either expensive to interact with or difficult to securely use on-chain. Through in-depth analysis, we summarized these issues as a lack of visibility. Therefore, we temporarily paused the development of Ourspace (we will continue to develop it later) and focused on researching the "visibility" issue, discovering that rollup technology is a good solution to this problem. The data availability layer is the first step in achieving this, and after extensive research, we designed Melodot. The work we have completed so far includes: + +1. [Whitepaper](https://www.notion.so/zerodao/Melodot-Data-Availability-Layer-Whitepaper-b72b1f3de81c40fc94a56763756ce34a): Completed a preliminary whitepaper. +2. [Research](https://zerodao.notion.site/Rollup-product-tracking-research-b9448e4464404736858e55972ea12152): We conducted some research on Rollup and data availability layer projects, and you can see the project list here. + +## Development Roadmap + +### Overview + +- **Total Estimated Duration:** 4.5 months +- **Full-Time Equivalent (FTE):** 1.5 +- **Total Costs:** 28,000 DAI + +### Milestone 1 — Erasure coding and KZG + +- **Estimated duration:** 1 month +- **FTE:** 1 +- **Costs:** 5,000 USD + +| Number | Deliverable | Specification | +| ------- | ------------------------- | ------------------------------------------------------------ | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how the new functionality works and how they are used. | +| **0c.** | Testing and Testing Guide | Unit tests will completely cover the Core functionality to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide Dockerfiles to demonstrate the full functionality of erasure coding and KZG commitments. | +| 1. | melo_erasure_coding | The core part of the system, including 2D erasure coding and KZG commitment-related primitives and common interfaces. | + +### Milestone 2 — Consensus + +- **Estimated duration:** 1.5 months +- **FTE:** 1 +- **Costs:** 7,000 USD + +| Number | Deliverable | Specification | +| ------- | ------------------------------ | ------------------------------------------------------------ | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can spin up a client, connect to the client management application and data through a browser, and create a local development chain. | +| **0c.** | Testing and Testing Guide | Higher-level integration tests and unit tests for all modules. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide Dockerfiles to start nodes, create a local test network, and run all integration tests. | +| 1. | Substrate pallet: excutive_das | Modify the existing `frame-executive` pallet to support custom headers while ensuring all original tests continue to function. | +| 2. | Substrate pallet: system_das | Extend the `frame-system` pallet to support the creation of extended headers. | +| 3. | Substrate pallet: melo_store | A core pallet for handling data availability. Main features include: 1) Registering applications. 2) Allowing users to submit data metadata. 3) Validators accessing off-chain storage via OCW and reporting unavailable data. 4) Interface for creating extended block header. | +| 4. | melodot-client | A substrate client containing a complete data availability layer. The DAS core features include: 1) Accepting user-submitted blob_tx, verifying if the data is correctly encoded, submitting the transaction, and publishing the data to a peer-to-peer network 2) Validators retrieving data transactions from the transaction pool and attempting to fetch the data from DHT to save locally. | + +### Milestone 3 — Sampling + +- **Estimated duration:** 1 month +- **FTE:** 1.5 +- **Costs:** 7,000 USD + +| Number | Deliverable | Specification | +| ------- | ------------------------- | ------------------------------------------------------------ | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can start a light client and connect to the network. | +| **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 Dockerfiles to start a light client, connect to the local test network, and run all integration tests. | +| **0e.** | Article | We will publish an article explaining how Melodot works, how to run a local test network, and how to run a light client. | +| 1. | Light client | A light client that connects to the network and efficiently performs sampling, stores sampling data, and maintains data availability confidence. | +| 2. | melo_sampling | A decoupled sampling module that provides core functionality related to data sampling. | + +### Milestone 4 — Farmer + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **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 run a farmer client and earn rewards. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| **0e.** | Article | We will publish an article explaining the farmer part and the future plans for Melodot, as well as how to run a farmer client. | +| 1. | melo_farmer | Implementation of the farmer client, used to connect to the melodot-client, solve challenges, and distribute and store data. | +| 2. | melo_PoSpace | A pallet used to assign distributed generation tasks to farmers and distribute rewards to farmers. | + +## **Future Plans** + +In the near future, we plan to establish a company as the core development team. Our long-term plan is to build the entire ecosystem through a DAO, and we have already formulated a centralized version of the DAO to be developed after the launch of the Melodot testnet. + +Our short-to-medium-term plan (6 months) includes: + +Melodot + +- Launch the testnet +- Identify and eliminate all possible security threats +- Complete the full PoSpace and distributed generation + +SDK + +- Develop an SDK based on Substrate for quickly launching settlement layers and sequencer + +## Additional Information➕ + +**How did you hear about the Grant Program?** + +Web3 Foundation website + +- Previous grant applications + +We have previously applied for ZeroDAO-node, which has now been renamed to ([ourspace](https://github.com/ZeroDAO/ourspace)). diff --git a/applications/Meta_Defender.md b/applications/Meta_Defender.md new file mode 100644 index 00000000000..0f19839623a --- /dev/null +++ b/applications/Meta_Defender.md @@ -0,0 +1,369 @@ +# Meta Defender + +- **Team Name:** Meta Defender Team +- **Payment Address:** 25r4oZedLXEunTmdvytyH4xcmQqqWWw8KmphdiD5LqpU29pv （aUSD） +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1089#issuecomment-1484905533) + +## Project Overview :page_facing_up: + +### Overview + +Meta Defender is a decentralised insurance protocol built on the blockchain. It is developed with ink! smart contract, and is designed to provide insurance for transactional and non-transactional assets on the blockchain of users. Later on, it will support cross-chain insurance through substrate and XCM. In the meantime, Meta Defender is also working to apply blockchain technology to real-world insurance scenarios, becoming an important addition to the traditional insurance industry. This project is the first-place winner of Acala Hackathon and is in the 2022 cohort of Web3.0 Bootcamp supported by Web3.0 Foundation and Parity. + +The rapid development of Defi has led to a huge increase in the digital assets that are transactional in smart contracts, which also makes it very vulnerable to cyber attacks. Conventional insurances, on the other hand, have limited capacity to provide transparent, secured and rapid protection for precious assets. In order to cater for the increasing needs, our team decided to work on a Defi insurance protocol, also to solve several pain points in existing web3 insurance products. + +Meta Defender is planned to launch on the parachains in the Polkadot Ecosystem, designed to provide insurance services to multiple subject-matters in the Polkadot Ecosystem. + +### Project Details + +### 1. Mockups/designs of any UI components + +- Homepage + +

          1

          + +- Buy Cover + +

          2

          + +- Become an underwriter + +

          3

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

          + +

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

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

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

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

          + +The sToken is not a transferable ERC20 token; it is simply a credit to the underwriter by the pool as a credential to capture premium rewards and withdraw assets in the future. + +At the time each pool is created, the starting value of η is 1. Given that pay-outs of claims are prioritised through the Mining Pool balances for claims(Risk Reserve), the value of η is maintained at 1 as long as there is no large-scale claims event resulting in an encroachment on the Capital Reserve's principal. + +#### 4.2.1 Global Variables + +- η: the exchange rate of Token to sToken; +- accumlatedRewardPerShare (accRPS): 1 sToken's accumulated captured premium reward; +- accumulatedShadowPerShare (accSPS): 1 sToken's accumulated "captured" risk; +- accumulatedShadowPerShareDown (accSPSDown): the release (reduction) of accSPS as a result of policy expiration; +- latestUnfrozenIndex: For the most recent policy written off, the latest underwriters who joined the pool that covered this policy. Or in other words: "youngest one" (age = length of time in the pool) + + +#### 4.2.2 Data Structure of the Underwriter and the Policy + +When an underwriter stakes some Tokens to the protocol, the protocol marks him like this: + +- index: the order in which the underwriter joined the protocol; +- sTokenAmount: the number of sTokens acquired by the underwriter (i.e., A as the number of Token in the previous section); +- rewardDebt（RDebt）: ​sTokenAmount∗accRPS, the reduction factor for calculating the underwriter's capture of the reward; +- shadowDebt（SDebt）：sTokenAmount∗accSPS​, the reduction factor for calculating the underwriter's capture of the risk; +When a policy is created, the protocol will mark it as follows： +- coverage: the policy’s coverage, also the shadow that will be shared by all underwriters; +- ΔaccSPS:coverage/sToken.totalSupply,the incremental accSPS resulting from the policy - it will accumulate in accSPSDown when the policy expires; +- latestProviderIndex: the index of the last underwriters of the pool, which can be understood in conjunction with the latestUnfrozenIndex in the previous section + +#### 4.2.3 Policy Generation and Reward Capture + +After a policy is generated, we set the amount paid by policyholder as “fee”, and we have + +

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

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

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

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

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

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

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

          + +#### 4.3.3 After Underwriter Withdrawal of Assets + +In order to make the protocol easier to maintain and to reduce the cost of gas fee when users invoke the contract, Meta Defender currently requires the underwriter who would like to quit to withdraw all remaining liquidity at once (i.e., withdraw mentioned above). + +Of course, you may only want to "withdraw partially". It is very simple to implement this - you could simply withdraw in full and then re-join with your desired coverage amount. This saves the protocol from having to maintain a huge ledger, where the cost of gas would otherwise become unimaginable. + +When an underwriter withdraws assets, he or she needs to destroy all of his or her sToken. + +Suppose an underwriter P destroys all of his sToken, declaring that he has ended his status as an underwriter. Regardless of how much capital he has actually withdrawn (usually less than his original provided capital, i.e. η*sTokenAmount, less than ), he can no longer continue to capture premium and no longer underwrite new policies, i.e., no longer "capture" new shadow. + +The protocol creates a "historical identity" for him, P', and records the following parameters: + +fsToken(frozen_sToken): the number of Tokens that this underwriter has not withdrawn, which will be then converted to sToken according to current η; + +accSPS_P: the accSPS of P when it quits the protocol; + +index: the index inherited from P; + +sTokenAmount_P : the sTokenAmount inherited from P; + +SDebt_P: the sDebt inherited from P. + +It can be seen that the maximum amount that can eventually be released by P' is: + +η∗fsToken​ ------ ①; + +The shadow inherited by P' from P is: + +sTokenAmount_P*accSPS_P - SDebt_P + +Or + +sTokenAmount_P*（accSPS_P - accSPSDown）------- ②; + +Obviously, at this point ②>=①. + +Thereafter, the Meta Defender protocol monitors for changes in ②. As the earlier policies gradually expire and are cancelled as well as the capital is unfrozen, the value of ② gradually decreases (of course, the relationship between index and latestUnfrozenIndex is taken into account, and ② is really reduced when index \<= latestUnfrozenIndex. + +When ② < ①, the difference between ① and ② is the capital of P being unfrozen. P extracts it, updates the value of ① to ②, and waits for the next unfrozen part. + +As accSPSDown increases, the value of ② eventually goes to zero. Zero is the minimum value of ② and cannot be a negative number. + +After ① goes to zero, all residual capital of P finishes withdrawing. + +#### 4.4 Leveraged Liquidity Mining Rewards Mechanism + +The holder of sToken, i.e. the underwriter of Meta Defender, is entitled to the Leveraged Liquidity Mining rewards. + +In order to encourage underwriters to provide long-term, stable capital, sToken holders are required to hold their sTokens for a certain period of time (approximately 14 natural days, with minor variations depending on the speed of block creation on the mainnet) before they can participate in the withdrawal of this Rewards. + +After withdrawing from the Capital Reserve and destroying the sToken, the holder will lose the eligibility to withdraw the proceeds. The mining proceeds will be hosted separately by Meta Defender's governance contract and will be claimed from the pool for sToken. + + + + +### Ecosystem Fit + +- Where and how does your project fit into the ecosystem? + +Meta Defender will use the stablecoin in parachains as the currency for buying cover, underwriting and for payouts of claims. Currently Meta Defender is planned to be deployed with ink! Smart contract and compatible with Substrate and XCM. Ultimately, we would like to provide insurance services to the main parachains and major protocols in the Polkadot Ecosystem. Also, by introducing XCM, we would like to achieve cross-chain insurance. + +Our Leveraged Mining component will cooperate with top liquidity mining protocols in Polkadot Eco, which will increase the TVL of those projects. + +We are planning to integrate the Blockchain Oracles function in the Polkadot Ecosystem，e.g. Phala, which will expand our insured subject-matters to more off-chain scenarios. + +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? + +Our target audience will be the users who would like to buy covers for their digital assets in the Polkadot Ecosystem, as well as those who would like to utilise their idle capital to become an underwriter and gain proceeds from Liquidity Mining in the Polkadot Ecosystem and rewards from our insurance protocol. + +- What need(s) does your project meet? + +As the rapid development of Defi markets, asset holders are looking for an insurance protocol that can protect them when emergencies like theft, cyber attack and data leakage happen. Meta Defender is designed for providing such services. + +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? + +There is an insurance protocol called Nsure that received a grant from W3F. Meta Defender has following highlights compared to Nsure： + +Meta Defender’s pricing model is an upgraded Automated Market Maker Model purely based on the relations between supply and demand. Therefore, there is no need to manually adjust the factors for calculating the premium rates because it's auto-generated. + +Meta Defender’s Leveraged Mining will cooperate with Liquidity Mining protocols in the ecosystem while Nsure has their own capital mining pool. We believe, cooperating with top Liquidity Mining protocols in the ecosystem will maximise the returns with the capital that underwriters inject to the protocol. + +We are also planning to provide insurance service for more off-chain scenarios by integrating blockchain oracles, such as flight cancellation insurance. + +## Team :busts_in_silhouette: + +### Team members + +- Name of team leader: Alvin, CEO +- Names of team members: Angie, Fullstack Engineer & 0xdeadbeef, Fullstack Engineer + +### Contact + +- **Contact Name:** Alvin Lu +- **Contact Email:** 0xhikarilab@gmail.com +- **Website:** metadefender.finance + +### Legal Structure + +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A + +### Team's experience + +Alvin: With a background in financial investing and insurance consulting, as well as working a Tech Lead in a Venture Capital, Alvin brings his varied experience to Meta Defender. Alvin is also the external consultant for two AI based projects of China Life Insurance Company, namely an operational decision making tool and a fraud detection technology. He also has massive experience in blockchain, by constructing a DEX and IDO platform. He would like to integrate his expertise in Web3.0 with knowledge in insurance industry and provide a better solution to Blockchain insurance. + +Angie: Angie is a Data Scientist in a ASX-listed Fintech in Australia. She has extensive experience in Finance industry since 2017 and has profound understanding regarding tech utilization in finance industry. Using her expertise, she co-designed the pricing model and business flow of Meta Defender. She is also a crypto enthusiast and fascinated by She masters Solidity, Python Vue.js and Node.js. + +0xdeadbeef: He is a web3.0 coder and researcher for more than 4 years. He has a master's degree from Shanghai Jiaotong University and a major in finance. He masters solidity, Golang, Rust, Python, and Nodejs. In his past working experience, he worked for a public chain company and researched and developed on-chain DeFi projects, especially in options markets. He has much experience in EVM compatible blockchains. Recently, he has been passionate about insurance, which may be a new area in DeFi. Through his working experience in the on-chain option market, he considered there are many similarities between options and insurance. + +### Team Code Repos + +**Team Repo** + +- https://github.com/Meta-Defender/ +- https://github.com/Meta-Defender/Meta-Defender-Contract-V3 + + +**Team Member** + +- https://github.com/lutianzhou001 +- https://github.com/327istesting +- https://github.com/Angie-Sheng + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 8 months +- **Full-Time Equivalent (FTE):** 2 +- **Total Costs:** 8,000 USD + +### Milestone 1 — Basic Functionalities + +- **Estimated Duration:** 7.5 months +- **FTE:** 2 +- **Costs:** 4,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how to deploy and use the ink! smart contract. | +| 0c. | Testing Guide | Core functions will be covered by unit tests, along with detailed explanation step by step. | +| 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 1. | ink! smart contract | An ink! smart contract that will enable the digital assets holders to buy cover and the capital holder to become an underwriter. | +| 2. | Front-end e2e test | We will use Cypress.io as an e2e testing framework for the Front-end automated test. | + +### Milestone 2 Substrate + XCM + +- **Estimated Duration:** 6 months +- **FTE:** 2 +- **Costs:** 4,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 Meta Defender protocol enables cross-chain insurances. | +| 0c. | Testing Guide | Core functions will be covered by unit tests, which will be considered as another way of explanation | +| 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article** that explains the functionalities Meta Defender provides, which will cover: 1. auto-pricing model; 2. economic model of insuring and underwriting; 3. how we achieve cross-chain insurance through substrate and XCM and open source this part of code. | +| 1. | Cross-chain support | Establish a local parachain testnet and two local parachains A and B with sovereign account in each other. With smart contract deployed on A parachain, allow the user to buy cover and receive his claim from addresses on the B parachain through XCM. | +| 2. | Manual of interaction between ink! and front-end | We will provide a manual regarding constructing an interface for the interaction between front-end and ink! smart contract & Polkadot.js wallet, just like what web3.js and ethers.js have done in the EVM ecosystem. | + + +## Future Plans + +Short-term plan: Expand the subject-matter insured. We plan to provide insurance on at least five parachains and/or products running on them in the Polkadot Ecosystem. + +Medium-term plan: With the aid of blockchain oracles function, to cover real-life off-chain cases. A potential use case can be flight cancellation insurance. + +Long-term: We would like to cooperate with professional security service providers and to undertake detailed risk analysis on the subject-matter insured and potential projects, which enables us to issue security rating reports and become the security rating agency in web3.0 realm. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Meta Defender is the first-place winner of Acala Hackathon: https://twitter.com/AcalaNetwork/status/1527290444379394049?s=20&t=u60vX2VZTWvSoZ1x62Y-sA + +Meta Defender is also in the 2022 cohort of Web3.0 Bootcamp supported by Web3 Foundation, Parity and Wanxiang Blockchain Labs. + +Since we have participated in a few activities in the Polkadot Ecosystem and have a profound understanding of the eco, we have been advised that we could apply for the grants program and grow with Polkadot. diff --git a/applications/MigrationEase.md b/applications/MigrationEase.md new file mode 100644 index 00000000000..ac3072e9cd0 --- /dev/null +++ b/applications/MigrationEase.md @@ -0,0 +1,176 @@ +- **Team Name:** Zondax AG +- **Payment Address:** DOT/AssetHub address 1fN87Fgj5BUhezFgbLiGbXTMrBVggnmYBX9anzMBky8KaJ5 +- **[Level]**: 3 + +## Project Overview :page_facing_up: + +The recent release of the new [Ledger Application for Polkadot](https://zondax.ch/blog/all-in-one-polkadot-app-is-here-2) delivers significant advantages by consolidating multiple substrate-based chains into a unified, secure Ledger application. This marks a major improvement for users managing assets across the Polkadot ecosystem. + +However, migrating funds from older Ledger-based accounts to this new application remains challenging for many users. The issue is not with the Ledger app itself, but with the lack of a user interface that could guide them through the migration process. + +The migration process is today still largely manual. This complexity creates barriers for users who want to adopt the new Polkadot Universal app but struggle with the current migration workflow. + +This project aims to simplify the migration process, making it more accessible to the broader Polkadot community. + +The application will allow users to connect their Ledger devices and guide them step-by-step through the migration process. The application will indicate which accounts or apps can be migrated immediately, and which ones may not yet be eligible for migration, offering transparency and reducing confusion. + +### Overview + +The primary goal of this project is to create an intuitive, user-friendly interface that simplifies the migration process for Polkadot and Parachain Ledger users. + +This web application will allow connecting Ledger devices, automatically display accounts eligible for migration, and assist users through the migration process in a secure and clear manner. + +### Project Details +#### Technology and Languages + +Frontend +Next.js +MUI +Typescript +Ledger Integration Libraries + +Backend +Integrating indexing infrastructure / APIs + +### Ecosystem Fit + +Zondax is a growing and distributed team with experience and projects for more than 50 blockchains. Zondax has been contributing to the Substrate ecosystem since 2018-2019. The team has received and completed a large number of W3F grants and currently maintains most Ledger apps for the ecosystem. + +## Team :busts_in_silhouette: + +### Team members + +- 1 x Fullstack Engineer +- 1 x Frontend Engineer +- 0.5 x Project Manager +- 0.2 x DevOps Support + +### Contact + +- **Contact Name:** Juan Leni and Ainhoa Aldave +- **Contact Email:** juan.leni@zondax.ch / ainhoa.aldave@zondax.ch +- **Website:** zondax.ch + +### Legal Structure + +Legal structure +Zondax AG +Dammstrasse 16 +Zug 6300 +Switzerland +UID CHE-491.796.576 + +### Team's experience + +Over the last few years, Zondax has been involved in a large number of projects for most of the key players in the blockchain industry. Our team includes experts in most blockchain aspects, from cryptography to data and protocol engineering. +### Team Code Repos + +Most of our contributions to the blockchain ecosystem can be found in our GitHub organization [zondax](https://github.com/zondax) + + +## Development Status :open_book: + +Not initiated. + +## Development Roadmap :nut_and_bolt: + +## Technical Scope: + + +### Milestone 1 Initial UI & Basic Functionality + +In this milestone, we will deliver a minimal user interface (UI) that allows users to connect to a Ledger hardware device and interact with their accounts with the objective to facilitate the Migration process from old accounts to the new Polkadot generic app. + +The core features include: +- **Connect to Ledger Hardware Device**: Users will be able to securely connect their hardware wallets when using the polkadot generic and migration apps previously developed by Zondax. +- **Scan and View Accounts**: The app will scan the connected devices and display all relevant accounts, allowing users to view their account balances. +- **Balance Overview**: Users can easily check the balance of their accounts, including unstaked/available funds. +- **Transfer and Account Management**: For accounts that are not locked (e.g., due to staking or other restrictions), users will be able to transfer accounts and send funds. This will include the transfer of NFTs. + +### Milestone 2 Advanced Flows and Improvements + +In this milestone, we will extend the functionality of the application by introducing advanced account management and support for additional flows. Key deliverables include: + +- **Facilitated Staking/Unstaking**: The application will facilitate the staking and unstaking process, providing users with a simplified flow to stake or unstake their assets and informing them about at what stage they’re able to initiate the account migration process. Additionally, the app will streamline workflows for handling common asset locks associated with voting and delegations. It will also support a visual guide for handling other common locks tied to standard pallets, assisting users through a manual unlock process when needed. +- **Kusama, AssetHub and 5 Parachain Support**: The app will support interactions with up to 5 parachains, this will be done as a reference, extensibility is described in the following point. +- **People chain support**: the application will facilitate specific actions on the People chain, such as removing identity and transfer of unreserved funds. +- **Simplified Management of proxies, multisig and decision deposits**: the application will include workflows for managing proxies, multisig accounts and decision deposit reserves, making these processes more user-friendly. +- **Configuration and Documentation**: We will provide a standardized configuration and documentation so compatible parachains can provide parameters, logo and other information to contribute to the current application. +- **Enhanced User Experience**: Optimized flows and improved waiting time display for transactions, specifically when dealing with Kusama’s AssetHub and parachains. + +### Milestone3 Maintenance and improvements + +Ongoing maintenance and operation of the application for a period of 12 months. +We will cover all costs for the operation of the website, we can provide monitoring information similar to checkly. + +Modifications and updates to ensure optimal performance and address any issues +Includes maintenance of the Migration Ledger App without the addition of new features. +Continue support for features that are moved from the relay chain to Asset Hub: staking, OpenGov, balances. + +It does not include technical support for parachains teams. + +### Overview + +- **Total estimated workload:** 2 months +- **Delivery time:**: 3 months +- **Full-Time Equivalent (FTE):** 2.7 FTE +- **Total Costs:** 87'000 USDT +- **DOT %:** Percentage of Total Costs to be paid in (vested) DOT = 50% + +### Milestone 1 Initial UI & Basic Functionality + +- **Estimated workload:** 1 month +- **Delivery time:**: 1.5 months +- **FTE:** 2,7 +- **Costs:** 37'500 USDT + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT | +| **0b.** | Documentation | We will provide a inline documentation of the code and inline documentation of the code and a basic tutorial | +| **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/Tutorial |Initial article/tutorial explaining the project and how to use the web application | +| 1. | PoC code| General structure | +| 2a. | Code| Connect to Ledger Hardware Device | +| 2b. | Code| Scan and View Accounts | +| 2c. | Code| Balance Overview | +| 2d. | Code| Transfer and Account Management | + +### Milestone 2 Advanced Flows and Improvements + +- **Estimated workload:** 1 month +- **Delivery time:**: 1.5 months +- **FTE:** 2,7 +- **Costs:** 37'500 USDT + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT | +| **0b.** | Documentation | We will provide a inline documentation of the code and inline documentation of the code and a basic tutorial | +| **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/Tutorial | We will publish the final article/tutorial explaining the project and how to use the web application | +| 1. | PoC code| General structure | +| 2a. | Code| Facilitated Staking/Unstaking | +| 2b. | Code| Kusama AssetHub and 5 Parachain Support | +| 2c. | Code| Simplified Management of proxies, multisig and decision deposits | +| 2d. | Code| Standardized configuration and documentation | +| 2e. | Code| Enhanced User Experience | + +### Milestone3 Maintenance and improvements + +- **Estimated workload:** 1 month +- **Delivery time:**: 12 months +- **FTE:** 0,3 +- **Costs:** 12'000/ USDT - We request a payment of $3k per quarter. + +Maintenance and operation for 12 months + +## Future Plans + +Depending on the traffic and feedback from the community, we may extend functionality beyond this current contract. + +## Additional Information :heavy_plus_sign: + +Zondax has been contributing to the Polkadot ecosystem for several years, and has successfully completed several grants. diff --git a/applications/Multix-a-simple-UI-for-complex-multisig.md b/applications/Multix-a-simple-UI-for-complex-multisig.md new file mode 100644 index 00000000000..e112bdd7915 --- /dev/null +++ b/applications/Multix-a-simple-UI-for-complex-multisig.md @@ -0,0 +1,138 @@ +# Multix a simple interface for complex multisigs + +- **Team Name:** ChainSafe +- **Payment Address:** 0x85D81Ab61Fe16CDcaeF2Ca556ED4577A51b9b07C (DAI) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + + +## Project Overview :page_facing_up: + +In response to an ask byt Web3F and Parity. + +### Overview + +Multiple signature requirements can be attractive to organizations seeking protection against a single signer misappropriating funds in a single-sig wallet. +Polkadot and Kusama both have a `multisig` pallet that all users to submit transactions as part of a multi-sig wallet, however the experience around using it is not great. There are several issues around it. The first and probably most critical one is that the multi-sig address that is created once one selects a set of signatories and a threshold is deterministic. It means that if any of the signatory changes, or if the threshold changes, the address of the wallet will change as a result. In an enterprise level setup, it is not uncommon to add/rotate signatories. Having the wallet address changing as a result is not acceptable. Another annoyance that multisig users need to deal with is the fact that they need to have off-chain communication with other signatories in order for the last signatory to submit the pre-image hash, also called `callData` for the last signer to be able to submit the extrinsic. Finally, there is not today a dedicated interface that is easy to use to allow users to create and manage their multisig accounts. + + +### Project Details + +The goal of the project is to solve the above mentioned issues, with the use of existing pallets, namely the `utility` pallet, the `proxy` pallet and obviously the `multisig` pallet. Pure proxies, while adding some complexity to the setup, allow for great flexibility. The interface needs to make sure that these are abstracted as much as possible to make the experience as pleasing as possible. + +The interface should: +- Make address generation easy (users need to supply member/threshold) +- Show the user what calls are pending +- Allow users to approve calls and submit the extrinsic for the last signer +- Optionnaly, the UI should allow to make a transfer + +The system should: +- Allow signatories to be rotated without changing the wallet address +- Allow threshold to be changed without changing the wallet address + +Note that at first, the interface will be minimal and focus on multisig creation and signing. Other feature requests such as the flow to rotate signatories, make more complex extrinsics from the UI or add some proxies to the multisig are no-brainer next steps but are not part of this first proposal. + + +### 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? +This projects aims at democratizing the use of multisigs in the Polkadot/Kusama ecosystem, which is a safe way of handling funds. Multisigs are a key element to get Enterprises and DAOs onboarded onto the ecosystem. + +- Who is your target audience? +Mainly bigger structures, enterprises and DAOs. + +- What need(s) does your project meet? +This has been clearly stated above I think, it solves the current shortcommings of what is available using simple multisigs, and brings it into a nice experience. + +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? +There are many multisig UIs, such as on Subscan or even using the Polkadot-js apps UI but I don't believe that anything like this is available today in the Polkadot ecosystem. In Ethereum however, billions are currently secured by the Safe (formerly gnosis safe) smart contract multisigs. + +## Team :busts_in_silhouette: + +### Team members + +- Thibaut Sardan @tbaut + +### Contact + +- **Contact Name:** Thibaut Sardan +- **Contact Email:** thibaut@chainsafe.io +- **Website:** chainsafe.io + +### Legal Structure + +- **Registered Address:** 251 Spadina Ave, Toronto, Ontario, M5T 2E2, Canada +- **Registered Legal Entity:** ChainSafe Systems + +### Team's experience + +Thibaut worked at Parity for more than 3 years, he has extensive experience in building wallet related UIs and flows, and has been a key contributor to the Polkadot ecosystem accross projects such as Parity Signer, Polkadot-js extension and apps, Polkassembly... + +### Team Code Repos + +- https://github.com/ChainSafe +- https://github.com/tbaut + +## Development Status :open_book: + +No designer is involved in a first step, to validate the flows and start small. Here are mocks of the creation flow. +![Selection_1150](https://user-images.githubusercontent.com/33178835/213197827-24473adb-965e-4951-92cd-4a55f7e31608.png) + +Upon cration, a proxy will be created and signatories will need to approve it. +![Selection_1151](https://user-images.githubusercontent.com/33178835/213197846-289176da-0364-4665-9fe3-ebd3ce55d8df.png) + +Once the first proposal approved, the multisig and its (abstracted) proxy are ready to use. +![Selection_1152](https://user-images.githubusercontent.com/33178835/213197862-f3e562e8-a12f-40a8-a694-ccb5c42e8c3d.png) + +## 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/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. + +For each milestone, + +- make sure to include a specification of your software. _Treat it as a contract_; the level of detail must be enough to later verify that the software meets the specification. +- include the amount of funding requested _per milestone_. +- include documentation (tutorials, API specifications, architecture diagrams, whatever is appropriate) in each milestone. This ensures that the code can be widely used by the community. +- provide a test suite, comprising unit and integration tests, along with a guide on how to set up and run them. +- commit to providing Dockerfiles for the delivery of your project. +- indicate milestone duration as well as number of full-time employees working on each milestone. +- **Deliverables 0a-0d are mandatory for all milestones**, and deliverable 0e at least for the last one. If you do not intend to deliver one of these, please state a reason in its specification (e.g. Milestone X is research oriented and as such there is no code to test). + +> :zap: 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! **Teams that submit others' work without attributing it will be immediately terminated.** + +### Overview + +- **Total Estimated Duration:** 1 month for an engineer full time + finance department +- **Full-Time Equivalent (FTE):** 1.5 FTE +- **Total Costs:** 30000 + +### Milestone 1 - Create and manage multisig calls + +- **Estimated duration:** 1 month +- **FTE:** 1.5 +- **Costs:** 30000 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 create a multisig. The steps should be self explanatory for anyone having basic multisig knowledges. | +| 0c. | Testing Guide | The scope of this project being too small, no testing will be done in a first step. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone.. | +| 0e. | Article | We will publish an **article** that explains the basics of multisigs and show the benefits of using this interface to create more complex multisigs. +| 1. | creation screen | Users will be able to create a multisig based on a list of signatories and a threashold. | +| 2. | indexer | To provide a smooth user experience, a subsquid indexer will make sure to track multisig interractions. The Docker will be made available | +| 3. | home screen | The home screen will allow to select the available multisig and see the signatories, the threshold along any pending request | +| 4. | request approval | Upon reviewing pending approvals, users are able to approve pending approvals and submit the final extrinsic without any external communication with other signatories. | +| 5. | pallet support | The multisig will be based on the `[mutlisig](https://github.com/paritytech/substrate/tree/master/frame/multisig)` pallet, also using `[proxy](https://github.com/paritytech/substrate/tree/master/frame/proxy)` and `[utility](https://github.com/paritytech/substrate/tree/master/frame/utility)` pallets to handle the different flows.| +| 6. | stack | Both front-end and back-end are using Typescript. The front-end is built using React, it will connect to a blockchain node for live information such as the pending proposals, and to user wallets such as Polkadot-js extension to allow users to sign extrinsics. The backend is made of a subsquid indexer that is tracking multisig interractions.| + +## Future Plans + +As mentioned above, this is requesting the funding to get things started with a functionnal UI, wihout too many bells and whisles. Many needs have already been identified for institutions and DAOs. Chainsafe is dedicated to make this the stepping stone of a long road. +Other features such as the flow to rotate signatories, make more complex extrinsics from the UI or add some proxies to the multisig can be added at next steps. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** At W3F and Parity's request diff --git a/applications/NFTStore_Network.md b/applications/NFTStore_Network.md index e9dddd1eceb..3fdda9ec848 100644 --- a/applications/NFTStore_Network.md +++ b/applications/NFTStore_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# NFTStore -* **Project:** NFTStore * **Proposer:** [NFTT Studio](https://github.com/NFTT-studio) * **Payment Address:** 1AeR4htoGwDRMpw7S2TTrzjJxeGLZsopiE diff --git a/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md b/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md index a9dbef69d15..5108a34a24d 100644 --- a/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md +++ b/applications/NFT_Bridge_Protocol_for_NFT_Migration_and_Data_Exchange.md @@ -1,31 +1,32 @@ -# Open Grant Proposal +# Protocol for NFT Migration and Data Exchange -* **Project Name:** Protocol for NFT Migration and Data Exchange -* **Team Name:** Perpetual Altruism -* **Payment Address:** -BTC : 1B6AHziiBvE28Lg74n23V3dYXbxcVLGKYi +- **Team Name:** Perpetual Altruism +- **Payment Address:** +BTC : 1B6AHziiBvE28Lg74n23V3dYXbxcVLGKYi ETH/DAI : 0xA7427d0D45e8dd969049872F9cDE383716A39B23 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/809#issuecomment-1160448332) -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: This proposal is in response to Polkadot Bridge RFP. + ### Overview -In this proposal, we use the following terms and definitions: +In this proposal, we use the following terms and definitions: -* *NFT:* Intangible asset that is compatible with the ERC-721 standard (i.e. the unique intangible asset is abstracted from the concept of token, which is how the asset is represented on a blockchain). An NFT always exists in a world, which is itself in a universe. +- *NFT:* Intangible asset that is compatible with the ERC-721 standard (i.e. the unique intangible asset is abstracted from the concept of token, which is how the asset is represented on a blockchain). An NFT always exists in a world, which is itself in a universe. -* *Universe* e.g. a blockchain or parachain, the Web2.0 internet, a private company’s database… +- *Universe* e.g. a blockchain or parachain, the Web2.0 internet, a private company’s database… -* *World (within a universe)* e.g. a smart contract or smart contract ecosystem, a website, a private company project… +- *World (within a universe)* e.g. a smart contract or smart contract ecosystem, a website, a private company project… -* *Migration:* The movement of an NFT from an origin universe to a destination universe. +- *Migration:* The movement of an NFT from an origin universe to a destination universe. -* *IOU migration:* An NFT migration where the original token is put in escrow in the origin universe bridge, and a deed that allows the bearer to redeem that original token in the origin universe is created in the destination universe. +- *IOU migration:* An NFT migration where the original token is put in escrow in the origin universe bridge, and a deed that allows the bearer to redeem that original token in the origin universe is created in the destination universe. -* *Full migration:* An NFT migration which is handled by the publisher of the NFT, who controls the destination world, and thus can allow the NFT’s features and intellectual property rights to be transferred to the new token in the destination universe. +- *Full migration:* An NFT migration which is handled by the publisher of the NFT, who controls the destination world, and thus can allow the NFT’s features and intellectual property rights to be transferred to the new token in the destination universe. -* *Digital Rights Management:* The systematic approach to prevent unauthorized redistribution of digital rights and intellectual property rights infringement during a full NFT migration. +- *Digital Rights Management:* The systematic approach to prevent unauthorized redistribution of digital rights and intellectual property rights infringement during a full NFT migration. The aim of this proposal is to standardize what information is sufficient and which are necessary to allow the migration of an NFT from an arbitrary universe to another. Both of the endpoints (origin universe/world and destination universe/world) must be ERC-721 compatible, but they do not have to be blockchains (e.g : domain name tokenization using an ERC-721 compatible API). @@ -35,126 +36,154 @@ There are already Polkadot bridges under development for ERC-20 tokens and other Our team is building NFT.com, a marketplace for the world’s tokenized assets and we need this infrastructure for our marketplace to work effectively on the Polkadot Network. Previous to this we also developed [Cryptograph](https://cryptograph.co), an NFT publisher and marketplace on Ethereum. ### Project Details + The deliverable of this proposal is a standardized protocol specification. -### Ecosystem Fit +### Ecosystem Fit + To our knowledge, there is currently no work being done on a standardized, universal bridge protocol for cross-chain NFT migration. ## Team :busts_in_silhouette: + ### Team members -* Guillaume Gonnaud -* Edouard Bessire + +- Guillaume Gonnaud + +- Edouard Bessire ### Contact -* Guillaume Gonnaud -* g.gonnaud@perpetual-altruism.org -* [NFT.com](http://NFT.com) -### Legal Structure -* Perpetual Altruism Ltd -* 2 Ordnance Mews, London NW86PF, United Kingdom +- Guillaume Gonnaud + +- g.gonnaud@perpetual-altruism.org +- [NFT.com](http://NFT.com) + +### Legal Structure + +- Perpetual Altruism Ltd + +- 2 Ordnance Mews, London NW86PF, United Kingdom ### Team's experience + **[Guillaume Gonnaud](https://github.com/Nokhal):** Co-Founder and CTO of Perpetual Altruism Ltd, the developer of NFT publisher and marketplace Cryptograph. Previously co-founded two other companies as CTO, and worked as a researcher and developer for Japan’s National Institute of Informatics in Tokyo. He holds a MSc Computer Science from France’s National Polytechnic Institute and a MSc Research in Artificial Intelligence from Paul Sabatier University. He is the main author of the [GBM auction mechanism](https://medium.com/cryptograph/incentivised-bidding-the-gbm-auction-c6dae5a756e5) as well as of the ERC-2665 standard. **[Edouard Bessire](https://github.com/edouardru):** Co-Founder of Perpetual Altruism Ltd, the developer of NFT publisher and marketplace Cryptograph. Computer science Engineer with extensive product development and project management experience. Edouard holds an MSc in Applied Mathematics from France’s National Polytechnic Institute, and an MSc in Innovation, Entrepreneurship and Management from the Imperial College Business School. He is also a co-author of the [GBM auction mechanism](https://medium.com/cryptograph/incentivised-bidding-the-gbm-auction-c6dae5a756e5). ### Team Code Repos -[https://github.com/Nokhal/Cryptograph_Project](https://github.com/Nokhal/Cryptograph_Project) -[https://github.com/ethereum/EIPs/issues/2665](https://github.com/ethereum/EIPs/issues/2665) + +[https://github.com/Nokhal/Cryptograph_Project](https://github.com/Nokhal/Cryptograph_Project) +[https://github.com/ethereum/EIPs/issues/2665](https://github.com/ethereum/EIPs/issues/2665) ### Team LinkedIn Profiles -[https://www.linkedin.com/in/guillaume-gonnaud/](https://www.linkedin.com/in/guillaume-gonnaud/) -[https://www.linkedin.com/in/edouardbessire/](https://www.linkedin.com/in/edouardbessire/) +[https://www.linkedin.com/in/guillaume-gonnaud/](https://www.linkedin.com/in/guillaume-gonnaud/) +[https://www.linkedin.com/in/edouardbessire/](https://www.linkedin.com/in/edouardbessire/) + + +## Development Roadmap :nut_and_bolt: -## Development Roadmap :nut_and_bolt: ### Overview -* **Total Estimated Duration:** Less than 7 weeks -* **Full-time equivalent (FTE):** 2 FTE -* **Total Work Days:** 66 days -* **Cost per work day:** £300 -* **Total Costs:** £19,800 (26862.66 USD/DAI) - -### Milestone 1 — Desirable Protocol Features -* **Estimated Duration:** ~2 weeks -* **FTE:** 2 FTE -* **Work Days:** 21 days -* **Cost per work day:** £300 -* **Costs:** £6,300 (8558.05 USD/DAI) -* **Deliverable:** A list of clearly defined, measurable features that the final bridges built using this vision should support, as well as how to test them using pseudocode. + +- **Total Estimated Duration:** Less than 7 weeks + +- **Full-time equivalent (FTE):** 2 FTE +- **Total Work Days:** 66 days +- **Cost per work day:** £300 +- **Total Costs:** £19,800 (26862.66 USD/DAI) + +### Milestone 1 — Desirable Protocol Features + +- **Estimated Duration:** ~2 weeks + +- **FTE:** 2 FTE +- **Work Days:** 21 days +- **Cost per work day:** £300 +- **Costs:** £6,300 (8558.05 USD/DAI) +- **Deliverable:** A list of clearly defined, measurable features that the final bridges built using this vision should support, as well as how to test them using pseudocode. We will write up and engage with the community to determine the desirable features of a NFT migration and data exchange messaging protocol. So far, we have determined that the protocol must allow for the following features: -* Migrate any ERC-721 token between EVM-compatible chains -* Migrate an NFT back and forth to get the original token back. -* Be ERC-1155 compatible -* Migrate an NFT outside of an EVM universe and redeem the same token back -* Migrate an NFT to an arbitrary world (as the owner of an NFT, you should be able to choose where you want the NFT to be migrated to and who will mint it i.e. the protocol is not restricted to a specific project) -* Have built-in protections against “bad” migration by preventing migration to non-registered destination worlds. -* Allowing polkadot parachains to trustlessly migrate NFTs from one parachain to an another using SPREE. -* Perform both IOU migration (no Digital Rights Management requirement) and Full migration (which requires Digital Rights Management at the bridge level) -* Migrate an NFT with either a ‘checked’ migration (need to be acknowledged by both the sender and the receiver of a token) or ‘unchecked’ migration (the token in the original world needs to first be attributed to a tokenID on the destination chain, then it is simply put in escrow with the bridge on the origin chain). NB: Checked migrations are fully trutless and decentralized and optimised for security, whilst unchecked migrations are optimised for gas costs. -* Licensed under the [Unlicense](https://unlicense.org) + +- Migrate any ERC-721 token between EVM-compatible chains +- Migrate an NFT back and forth to get the original token back. +- Be ERC-1155 compatible +- Migrate an NFT outside of an EVM universe and redeem the same token back +- Migrate an NFT to an arbitrary world (as the owner of an NFT, you should be able to choose where you want the NFT to be migrated to and who will mint it i.e. the protocol is not restricted to a specific project) +- Have built-in protections against “bad” migration by preventing migration to non-registered destination worlds. +- Allowing polkadot parachains to trustlessly migrate NFTs from one parachain to an another using SPREE. +- Perform both IOU migration (no Digital Rights Management requirement) and Full migration (which requires Digital Rights Management at the bridge level) +- Migrate an NFT with either a ‘checked’ migration (need to be acknowledged by both the sender and the receiver of a token) or ‘unchecked’ migration (the token in the original world needs to first be attributed to a tokenID on the destination chain, then it is simply put in escrow with the bridge on the origin chain). NB: Checked migrations are fully trutless and decentralized and optimised for security, whilst unchecked migrations are optimised for gas costs. +- Licensed under the [Unlicense](https://unlicense.org) ### Milestone 2 — Checked Migration Process -* **Estimated Duration:** ~2 weeks -* **FTE:** 2 -* **Work Days:** 20 days -* **Cost per work day:** £300 -* **Costs:** £6,000 (8150.52 USD/DAI) -* **Deliverable:** A documented step by step process that would allow a trusted relayer to perform efficient migrations of NFTs. + +- **Estimated Duration:** ~2 weeks + +- **FTE:** 2 +- **Work Days:** 20 days +- **Cost per work day:** £300 +- **Costs:** £6,000 (8150.52 USD/DAI) +- **Deliverable:** A documented step by step process that would allow a trusted relayer to perform efficient migrations of NFTs. We will write up the ‘Checked Migration’ process which includes a security protocol to ensure that both the sender and the receiver are satisfied with the migration outcome. This is especially important if NFT's are migrating from/to a trustless universe (eg : a public decentralized blockchain) toward/from a centralized/private universe. -This process is NOT a fully decentralized trustless process itself in order to accomodate for a wide array of possible origin and destinations, but it does allow decentralized trustless outcomes while guaranteeing authenticity and ownership of the NFT at every step. +This process is NOT a fully decentralized trustless process itself in order to accomodate for a wide array of possible origin and destinations, but it does allow decentralized trustless outcomes while guaranteeing authenticity and ownership of the NFT at every step. -* A checked migration process mean there is an acknowledgment of the migration on the destination universe by the sender. -* A checked migration process mean there is an acknowledgment of the migration on the origin universe by the receiver -* The migration is complete only once both the sender and receiver have acknowledged the migration. Before that, the migrated token cannot be used. -* If after a time-limit, either of those acknowledgement are missing, the migration is reverted : the original token can be withdrawn freely by the sender, and the migrated token is burned. -* Checked migrations need to be possible for either EVM => EVM, * => EVM or EVM => * migrations. -* Checked migrations need to allow any third party to "check" the migration and publish a standardized signed message that the migration did indeed happen. -* NB : This only cover the migration of NFTs to a new universe, not the redemption of the the NFT back to it's origin universe. -* Licensed under the [Unlicense](https://unlicense.org) +- A checked migration process mean there is an acknowledgment of the migration on the destination universe by the sender. +- A checked migration process mean there is an acknowledgment of the migration on the origin universe by the receiver +- The migration is complete only once both the sender and receiver have acknowledged the migration. Before that, the migrated token cannot be used. +- If after a time-limit, either of those acknowledgement are missing, the migration is reverted : the original token can be withdrawn freely by the sender, and the migrated token is burned. +- Checked migrations need to be possible for either EVM => EVM, *=> EVM or EVM =>* migrations. +- Checked migrations need to allow any third party to "check" the migration and publish a standardized signed message that the migration did indeed happen. +- NB : This only cover the migration of NFTs to a new universe, not the redemption of the the NFT back to it's origin universe. +- Licensed under the [Unlicense](https://unlicense.org) *The main purpose of this migration process is for NFT publishers to allow their users to effortlessly migrate their tokens with the least amount of efforts required. NFT publishers could offer users to do the whole migration with a single gas spending approve() from an NFT owner and the rest trough meta-transactions by the publisher. The publisher would then sign the migration as properly done after having minted and transferred the token on the destination blockchain. By essence, most NFTs are not trustless assets as their publishers own real world IP rights to them, and it is hence acceptable to use said publishers as relayers. This is standardizing a process that would otherwise require the publisher to update their original NFT smart contracts or NFT owners to burn their original NFT token in order to get a new one minted on the destination universe.* ### Milestone 3 — Trustless Migration Process -* **Estimated Duration:** ~1 week -* **FTE:** 2 -* **Work Days:** 10 days -* **Cost per work day:** £300 -* **Costs:** £3,000 (4075.26 USD/DAI) -* **Deliverable:** A documented step by step process that would allow a trust-minimized relayer to perform migrations of NFTs. + +- **Estimated Duration:** ~1 week + +- **FTE:** 2 +- **Work Days:** 10 days +- **Cost per work day:** £300 +- **Costs:** £3,000 (4075.26 USD/DAI) +- **Deliverable:** A documented step by step process that would allow a trust-minimized relayer to perform migrations of NFTs. We will write up the ‘Trustless Migration’ process which is designed to be used when the destination universe have trutsless state reading capabilities of the origin universe. -* Snowfork is already building a substrate module allowing specifically for Ethereum Smart contract reading. If a Substrate-built parachain implement those reading capacities, then implementation of this process should be straightforward. -* In the case of EVM => EVM ERC-721 migration without trustless reading, Chainbridge already exist. However, their contracts requires administrator input for new contract registration as well as lacking features that are NFT specific, such as preventing minting technically correct but legally counterfeit tokens. -* NB : This only cover the migration of NFTs to a new universe, not the redemption of the the NFT back to it's origin universe. -* Licensed under the [Unlicense](https://unlicense.org) + +- Snowfork is already building a substrate module allowing specifically for Ethereum Smart contract reading. If a Substrate-built parachain implement those reading capacities, then implementation of this process should be straightforward. +- In the case of EVM => EVM ERC-721 migration without trustless reading, Chainbridge already exist. However, their contracts requires administrator input for new contract registration as well as lacking features that are NFT specific, such as preventing minting technically correct but legally counterfeit tokens. +- NB : This only cover the migration of NFTs to a new universe, not the redemption of the the NFT back to it's origin universe. +- Licensed under the [Unlicense](https://unlicense.org) ### Milestone 4 — Standard and Documentation for Cross-universe Migration -* **Estimated Duration:** ~1 week -* **FTE:** 2 -* **Work Days:** 15 days -* **Cost per work day:** £300 -* **Costs:** £4,500 (6112.89 USD/DAI) -* **Deliverables:** - -* A generic Standard written in pseudocode including predicate and postulate for each function and events that would allow for either checked or trustless migrations to be performed for the same asset, from the same bridge : only one endpoint should be sufficient to know about all of the migrations. This standard is the most generic version and allows the most diverse universes, and henceforth is the least constrained. It will have it's own dedicated decentralized webpage explaining the standard as well as a documentation and links to both the EIP and the PSP. This decentralized webpage will also have a centralized, cached version that NFT.com will host. -* An EIP standard written in Solidity including predicate and postulate for each function and events that would allow for either checked or trustless migrations to be performed for the same asset, from the same bridge. -* A PSP standard written in ink! including predicate and postulate for each function and events that would allow a smart contract for either checked or trustless migrations to be performed for the same asset, from the same bridge. This would allow third parties to integrate an NFT bridge on any Smart contract supporting parachain, even if said parachain does not explicitely support a trustless communication channel with other parachains at the substrate level. As a separate module of this PSP we will also provide a standard for parachain NFT migrations using SPREE provided that both parachains implement this standard. -* Those standards must allow an EVM bridge following the EIP on ethereum mainnet/moonbeam to migrate an NFT to a WASM bridge following the PSP standard on a parachain and vice versa. + +- **Estimated Duration:** ~1 week + +- **FTE:** 2 +- **Work Days:** 15 days +- **Cost per work day:** £300 +- **Costs:** £4,500 (6112.89 USD/DAI) +- **Deliverables:** + +- A generic Standard written in pseudocode including predicate and postulate for each function and events that would allow for either checked or trustless migrations to be performed for the same asset, from the same bridge : only one endpoint should be sufficient to know about all of the migrations. This standard is the most generic version and allows the most diverse universes, and henceforth is the least constrained. It will have it's own dedicated decentralized webpage explaining the standard as well as a documentation and links to both the EIP and the PSP. This decentralized webpage will also have a centralized, cached version that NFT.com will host. +- An EIP standard written in Solidity including predicate and postulate for each function and events that would allow for either checked or trustless migrations to be performed for the same asset, from the same bridge. +- A PSP standard written in ink! including predicate and postulate for each function and events that would allow a smart contract for either checked or trustless migrations to be performed for the same asset, from the same bridge. This would allow third parties to integrate an NFT bridge on any Smart contract supporting parachain, even if said parachain does not explicitely support a trustless communication channel with other parachains at the substrate level. As a separate module of this PSP we will also provide a standard for parachain NFT migrations using SPREE provided that both parachains implement this standard. +- Those standards must allow an EVM bridge following the EIP on ethereum mainnet/moonbeam to migrate an NFT to a WASM bridge following the PSP standard on a parachain and vice versa. We will write up the standard and documentation for cross-universe migration, which includes “necessary” and “optional” data for optimization. This is a summarized write up of both the previous milestones but writen as specifications for implementations, including the predicate and postulate of each message and what they mean in term of state on the source and destination universe. -* Challenge: Establishing predicate and postulate on what are the allowed pair of source/destination worlds. Those allowed pairs could be designed in any fashion, from centralized trusted to decentralized and trust minimized. -* Licensed under the [Unlicense](https://unlicense.org) or when required under the license requirements of EIP and PSP. + +- Challenge: Establishing predicate and postulate on what are the allowed pair of source/destination worlds. Those allowed pairs could be designed in any fashion, from centralized trusted to decentralized and trust minimized. +- Licensed under the [Unlicense](https://unlicense.org) or when required under the license requirements of EIP and PSP. ## Future Plans + We will implement this standard for EVM-compatible chains. Our main goal is the ability for any Ethereum mainnet NFT to be painlessly migrated to Moonbeam on the Polkadot network. -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: + This proposal is a part of the wider NFT.com venture. -Learn more about our vision for the bridge here: [link](https://docs.google.com/document/d/1mhSKmC_4Hg7GqJuSLZk5Tu1hNjJlqo6O5TNwFx-e6vw/edit?usp=sharing) +Learn more about our vision for the bridge here: [link](https://docs.google.com/document/d/1mhSKmC_4Hg7GqJuSLZk5Tu1hNjJlqo6O5TNwFx-e6vw/edit?usp=sharing) diff --git a/applications/NeuroZK.md b/applications/NeuroZK.md new file mode 100644 index 00000000000..19bf68d2ae1 --- /dev/null +++ b/applications/NeuroZK.md @@ -0,0 +1,273 @@ +# NeuroZK - Empowering AI at the edge with zero-knowledge proofs. + +- **Team Name:** Cyborg Network +- **Payment Address:** 14zJseuDH5WvWXKKyc6svecBrLQ5CyoJkZN3SxYioRRC2ZsY (AssetHub USDT) +- **DOT Vesting Address:** 15p7mTm9uKt1w7GF3AU1TNPWm4eAHgieTjtfsVVEtqHazpaY +- **Level:** 2 + +## Project Overview :page_facing_up: + +![Untitled design (1)](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/a33de305-fba2-4a43-ac73-fe3736c03b56) + +### Overview + +This application is a follow up from our successful [grant delivery](https://github.com/w3f/Grant-Milestone-Delivery/pull/1196) + +Cyborg Network is developing a DePIN-based marketplace for edge computing resources, enabling latency-sensitive applications to scale globally with ease. Users can seamlessly offload specific low-latency workloads to edge locations while maintaining their core deployment in the cloud. Our vision is to serve as essential middleware at the network edge, orchestrating these tasks to reduce cloud operational costs and enhance existing cloud services. In response to user demand and recognizing the growing importance of distributed AI inference infrastructure, we are prioritizing the development of a decentralized AI compute platform leveraging ZK proofs as our go-to-market strategy. + +As part of our previous application, we delivered CyberDock, a product line focused on helping users deploy dockerized containers into our edge server network. We are now focusing on expanding this approach to a new product line called NeuroZK, which will enable AI apps to run Inference Engines backed by ZK proofs. + +Users can easily run GPU based inference engines in our crowdsoruced GPU network, with compute integrity verified using a ZK SNARK proof that proves that the inference algorithm was executed with 100% accuracy without revealing the actual inference algorithm nor the query or result data. + +We are on a mission to establish Cyborg Network as a Polkadot parachain. Our decision is anchored in several key reasons: + +First, we're enticed by their advanced interoperable features, such as shared security and XCM. These functionalities pave the way for seamless integrations with other projects within the ecosystem. We have already initiated talks with a few ecosystem teams like [Peaq](https://www.peaq.network/), [Tanssi](https://www.tanssi.network/), [Ava Protocol](https://avaprotocol.org/) for potential integrations. + +Second, the unparalleled ecosystem and technical support provided by Polkadot and Kusama have been instrumental in our development, and we've had the privilege of closely collaborating with them over the years. + +Lastly, the substrate framework stands out as the premier tool for crafting blockchains from the ground up in today's landscape. Our commitment to excellence aligns with the capabilities it offers. + +We will also be launching a line of pre-configured edge servers in partnership with [Simply NUC](https://simplynuc.com/), our hardware partner. Interested community members in high-demand locations will have the opportunity to purchase and operate these servers either in a co-location data center (recommended) or in their private facility (beta). They will be incentivized based on uptime guarantees and the work contributed to the network, similar to mining in PoW chains. + + +### Project Details + +#### Architecture: + +The core of our computing solution relies on both off-chain components and substrate pallets that work harmoniously with each other. + +Cyborg is a fusion of a blockchain network and numerous computing clusters, collaborating to offer an effective decentralized solution for verifiable off-chain computing. + +Our current goal is to leverage the potential of Substrate to enable coherence among geographically isolated worker nodes. This will create a blockchain-governed task distribution system based on load in different locations globally. + +![photo_2024-02-14_23-43-17](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/d50e7582-8f0f-461a-8668-10a828089404) + +The Substrate blockchain primarily serves as the framework for deploying containered tasks and facilitating smart contracts related to billing functions. + +Once the docker container is deployed, its workload will be protected by software based measures to prevent data leakage. + +It seamlessly integrates with the current cloud-native toolchain for developers, typically avoiding the need for code changes. + +Developers can monitor details such as resource utilization, and the app's health status through the Cyborg Connect application dashboard. + +![dashboard](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/90f160c6-5cef-408b-8db2-c3e550fdb6a8) + +### ZK Snark proof verification + +For this grant application, we will improvise our previous submission to make it live on Paseo and then proceed with developing a decentralized proof verification system to incorporate an on-chain ZK Snark system for verifying AI inference models executed in an off-chain environment. The main components will include the Cyborg AppChain (Deployed on Tanssi's Dancebox testnet), Cyborg Worker node (A custom node implementation to manage running offchain tasks and streaming proofs into pallets for verification), TEE Oracle, and a testing suite. + +The objective is to deploy a pre trained AI inference model in servers at different geographical locations based on user requirements. The Substrate blockchain will establish secure communication with worker nodes to issue commands for deploying, testing, and verifying model executions. + +We will define a new Substrate node configuration for the Cyborg worker nodes, which users can rent on-demand from the pool of available worker nodes. + +### ZK Proof Verification process + +Once a task is assigned to a particular worker node and it starts executing the task, at fixed intervals of time (currently arbitrarily set to 60 minutes), the ZK worker component in the worker node will generate a SNARK proof using the PLONK algorithm. We will use an oracle to convey this proof to the verifier pallet, which will evaluate the received proof using the verification key and public data inputs that the user submitted before execution. + +The pallet performs a series of elliptic curve operations and field arithmetic (over finite fields) to check the polynomial commitments and evaluations provided in the proof. The commitments must match the expected public inputs and satisfy the polynomial equations set by the PLONK circuit.Permutation arguments and other constraints encoded into the circuit are also validated at this stage. The Pallet checks whether all evaluations and commitments hold for the circuit, using the verification key. If they match, the proof is accepted as valid; otherwise, it is rejected. Once the verification succeeds, the transaction is processed as valid (e.g., approving the computation result). If the verification fails, the transaction is reverted or flagged as invalid. + + +### Ecosystem Fit + +Cyborg Network enhances the Polkadot ecosystem with decentralized edge computing, addressing the increasing demand for AI and IoT applications. We focus on Web2 application providers, opening doors for new users to join the Polkadot ecosystem and support its growth. We are also integrating enterprises that operate edge data centers into the Polkadot ecosystem. Some of our potential partners include [Edge Centres](https://edgecentres.com/) , [Deep Green](https://deepgreen.energy/) , [Heata](https://www.heata.co/) etc. + +Though Cyborg and the [Phala Network](https://phala.network/) share aspirations of decentralized computing within the Polkadot/Kusama environment, our technical paths and business aspirations are distinct. Phala Network provides off-chain compute infrastructure for smart contract-based applications by enabling users to integrate 'phat' contracts with their existing smart contract logic. While Cyborg is focused on creating utility for web2 applications. + +Another related project appears to be [Wetee](https://github.com/wetee-dao), which employs a comparable technical architecture utilizing TEEs to safeguard user privacy. However, their specific market focus is currently untraceable. + +![Write here](https://github.com/Cyborg-Network/Grants-Program/assets/93442895/a09109d1-e8f7-4ae5-8f4c-2eafc4b6ef6a) + +Our ultimate goal is to establish a decentralized edge computing network capable of executing targeted low-latency tasks to enhance system performance and efficiency. This approach aims to reduce the overall cloud footprint by providing an edge-to-cloud continuum, allowing users to augment our services with their existing cloud deployments. This, in turn, opens up new markets, particularly in real-time computation for edge AI and edge IoT devices. + +The technological landscape sees a plethora of competitors, each carving their niche with unique technical and market strategies. Renowned names include [Akash Network](https://akash.network/), and [Golem](https://www.golem.network/) . + +## Team :busts_in_silhouette: + +### Team members + +- [Barath Kanna](https://www.linkedin.com/in/barath-kanna) - Founder & CEO +- [Megha Varshini](https://www.linkedin.com/in/megha-varshini-t) - Founder & COO +- [Calvin Sze](https://www.linkedin.com/in/calvin-sze/) - Lead Fullstack Developer +- [Noor Mohammed](https://www.linkedin.com/in/noormohammedb/) - Substrate and Backend Developer +- [O Wahyudi](https://www.linkedin.com/in/sgid8t2c/) - Senior Backend Engineer +- [Tom Bleek](https://www.linkedin.com/in/tom-bleek-a7332b182/) - Front End Developer +- [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra) - Substrate Advisor + +### Contact + +- **Contact Name:** Barath Kanna +- **Contact Email:** barath@cyborgnetwork.io +- **Website:** https://cyborgnetwork.io + +### Legal Structure + +- **Registered Address:** 1111b South Governors Avenue, Dover, DE 19904 US +- **Registered Legal Entity:** ResoluteX Labs, Inc. + +### Team's experience + +- [Barath Kanna](https://www.linkedin.com/in/barath-kanna) - A developer with a specialization in Rust and blockchain technology. His experience is rooted in designing blockchain infrastructure solutions. Notably, he is an alumni of the Polkadot Blockchain Academy's third cohort at UC Berkeley (Jul - Aug 2023) + +- [Megha Varshini](https://www.linkedin.com/in/megha-varshini-tamilarasan-b1247a212) - She has been involved in operations for Web3 projects and has taken initiatives in the blockchain community. One of her contributions is the establishment of [Indi Verse DAO](https://www.linkedin.com/company/indi-verse-dao), a web 3.0 community in India. Additionally, she is the candidate of the Polkadot Ambassador Program. She is also a graduate from the Polkadot Blockchain Academy's Founders Track at Hong Kong (Jan - Feb 2024) + +- [Calvin Sze](https://www.linkedin.com/in/calvin-sze/) - Full Stack Blockchain Developer with 5 plus years of experience in blockchain development. He is a PBA alumni from Berkeley. + +- [Noor Mohammed](https://www.linkedin.com/in/noormohammedb/) - Noor Mohammed B is a skilled blockchain developer with a strong focus on backend development, DevOps, and system development. With over three years of experience in Rust programming, he has worked extensively on decentralized applications within the EVM and Polkadot ecosystems. Noor is also proficient in network programming and has contributed significantly to building scalable and secure backend systems. + +- [Tom Bleek](https://www.linkedin.com/in/tom-bleek-a7332b182/) - Tom Bleek is a dedicated and enthusiastic front-end developer focused on building high-performance front-end applications with an exciting appearance / Substrate and React developer focused on building secure blockchains and high-performance dApps with an exciting appearance. With his +experience in React and TypeScript Tom has played a key role in bringing projects to life, enhancing both the performance and user experience of complex web applications. + +- [Onggo Wahyudi](https://www.linkedin.com/in/sgid8t2c/) - Yudi is a specialist in backend development, with expertise in Rust and Substrate for blockchain projects. He excels in DevSecOps and AWS Cloud, and he graduated from the Polkadot Blockchain Academy in Singapore. + +- [Kresna Sucandra](https://www.linkedin.com/in/kresna-sucandra) - With three years of work in Rust, Substrate, and INK, Kresna has a foundational background in blockchain solutions. He was the former co-founder and head of protocol development at [Invarch Network](https://invarch.network/) (Polkadot and Kusama parachain). Beyond this, he is also a Polkadot Ambassador who manages the Polkadot Hub in Bali. + +### Team Code Repos + +Project GitHub repositories. + +- https://github.com/Cyborg-Network - Organization +- https://github.com/Cyborg-Network/cyborg-chain +- https://github.com/Cyborg-Network/cyborg-connect +- https://github.com/Cyborg-Network/Worker + +Team Github Handles. + +- https://github.com/beekay2706 +- https://github.com/ZCalz +- https://github.com/noormohammedb +- https://github.com/tom-blk +- https://github.com/oWahyudi +- https://github.com/Megha2712 + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/barath-kanna +- https://www.linkedin.com/in/megha-varshini-t +- https://www.linkedin.com/in/calvin-sze +- https://www.linkedin.com/in/noormohammedb +- https://www.linkedin.com/in/tom-bleek-a7332b182 +- https://www.linkedin.com/in/sgid8t2c +- https://www.linkedin.com/in/kresna-sucandra + +## Development Status :open_book: + +We have completed the development of an on-chain task verification system under CyberDock as a part of our previous grant application, it contained three parts - Substrate pallets, Front end app and k3s worker configurations. While task verification made more sense for batch files, we also developed log streaming to provide work proofs for continously running applications. + +7 + +Through this process, we identified the need for having a much simpler provider onboarding experience, so we are developing a custom node implementation called Cyborg worker nodes using which providers can connect their resources to the Cyborg parachain just by downloading and installing an executable file on their VMs. This also aligns with our focus to launch a plug and play hardware series called 'Cyborg miners' that directly connects to the parachain like an ASIC miner. + +Consequently, we will be delivering a ZK based offchain compute verification system, that validates the integrity of executing pre-trained AI models for decentralized AI inferencing on crowdsourced GPUs. For this grant we will use ZK and TEE to uphold data privacy in the system. + +We are also working concurrently on integrations with Peaq Network (DID pallet) and [CESS](https://cess.network/) for a decentralized storage product called CyStore. Additionally, we have garnered interest from Peaq to open an HRMP channel for XCM interactions between our chains once we are live. + +We have created a UX demo to understand our app flow [Cyborg Network UX demo](https://drive.google.com/file/d/1zrN4TRMDd5ON2xH9F00upcyK-3ofwV4r/view?usp=drivesdk) + +## Development Roadmap :nut_and_bolt: + +The grant delivery will have 3 distinct parts split into 3 milestones delivered every 2 months, + +1. TEE Oracle Implementation: + +* Develop an [ORML](https://github.com/open-web3-stack/open-runtime-module-library) based custom oracle for private and secure data exchange +* A custom pallet logic for handling the oracle +* UI updates for Oracle + +2. Development of Cyborg Worker Node: + +* Cyborg Worker Node defintion and configuration to enable compute providers to directly download executable and deploy worker nodes without clustering +* System Pallets for Cyborg parachain (Payments and Inventory) +* UI updates for Worker Nodes (Currently marked coming soon) + +3. NeuroZK - phase 1: + +* A RISC Zero based offchain ZK proof generation module +* Pallet implementation for proof verification +* System pallet for parachain (Worker Rewards) + +### Overview + +- **Total Estimated Duration:** 6 months +- **Full-Time Equivalent (FTE):** 2 ( 1 Full time Developer at 1 FTE/month and 2 part time developers each at 0.5 FTE/month) +- **Total Costs:** 30,000 USD +- **DOT %:** 50% + +### Milestone 1 - Cyborg Oracle Implementation + +- **Estimated duration:** 2 months +- **FTE:** 4 +- **Costs:** 10,000 USD + +#### **Deliverables:** + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how users can (for example) deploy docker images using our interface. | +| **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 deploy a local cyborg parachain and test the features of this delivery. | +| 1. | Working Demo | We will provide video documentation to help developers understand the process of testing the Orcale implementation.| +| 2. | Substrate Module: Oracle | This pallet will be responsible for establishing communication and regulating the use of an oracle. | +| 3. | Front end App: Cyborg Connect | Updated UI with features to display Task verification and result information from Oracle | +| 4. | Cyborg Oracle | An ORML based oracle implementation to seamless exchange data packets between cyborg parachain and connected offchain clusters| + + +### Milestone 2 - Cyborg Worker Node Implementation + +- **Estimated duration:** 2 months +- **FTE:** 4 +- **Costs:** 10,000 USD + +#### **Deliverables:** + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how users can launch a cyborg worker node using their local local machine| +| **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 run a cyborg worker node locally. | +| 1. | Working Demo | We will provide video documentation to help developers understand the process of connecting and managing a cyborg worker node.| +| 2. | Substrate Module: Payments | This pallet will be responsible for estimating the costs for executing a task based on server specifications and time. | +| 3. | Substrate Module: Inventory | This pallet will be responsible for uniquely mapping each worker node uniquely in the onchain inventory to keep track of server status. | +| 4. | Substrate Node implementation: Cyborg Worker | A custom node implementation to contribute compute power to the cyborg parachain and earn rewards for contributions| +| 5. | Cyborg Connect: Provide Compute (Feature) | The UI implementation to support deployment and management of Cyborg worker nodes| + +### Milestone 3 - ZK Verification Layer + +- **Estimated duration:** 2 months +- **FTE:** 4 +- **Costs:** 10,000 USD + +#### **Deliverables:** + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how users can (for example) deploy apps using yaml files through our interface | +| **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 a medium blog explaining the vision of NueroZK, current features and future plans | +| 1. | Testing suite | We will provide a testing facility to examine the working of ZK verification tool with the Cyborg parachain.| +| 2. | Substrate Module: ZK verifier | This pallet will be responsible for verifying and confirming proofs emitted by the offchain ZK worker through the cyborg oracle. | +| 3. | Cyborg ZK worker | A feature to the Cyborg worker node to posses specific instructions about ZK proof generation for a specific executed AI algorithm| +| 4. | Substrate module: Worker Rewards | A custom pallet that holds the logic of assigning rewards to commited worker nodes for executing user tasks | + + +## Future Plans + +- **Short term plans:** We intend to use the grant to develop the core functionality of Cyborg Network and also be encouraged to develop this product further to an MVP that can address latency issues in applications that work on real time data processing. +- **Long term plans:** We intend to build Cyborg Network into a comprehensive decentralized edge computing network, thereby unlocking novel markets, especially in real-time data management for edgeAI and edge IoT devices. We also plan to support additional features like edge server monetization, server hardware management and upgrades over time. + +## Additional Information :heavy_plus_sign: + +Cyborg Network was a part of the [Polkadot Relayers Incubator 2023](https://www.polkadotglobalseries.com/incubator/) and [Polkadot Encode Accelerator 2023](https://www.encode.club/encode-polkadot-accelerator-2023). + +We won the [web3hackx](https://www.hkweb3month.com/hackathon) Hackathon - Hong Kong (Nov 2023) in the Infrastructure track and Polkadot Bounty. + +Megha Varshini (COO) - represented Cyborg Network at the Finals (Top 7 teams) of the PBA pitch Contest in Hong Kong (Feb 2024) + +Kresna has contributed to the **InvArch's Web3 Foundation Grant** [Milestone 1](https://github.com/w3f/Grant-Milestone-Delivery/blob/7932b07cc38150701ba8ed034723193f66002975/deliveries/InvArch_M1.md) that has been completed successfully. He also contributed to the [Chocolate Network](https://substrate.io/ecosystem/projects/chocolate/) as a Substrate developer for their Substrate Builder Program (SBP) Milestone 1 delivery which has been completed successfully. + +Cyborg Network has been inducted into the [Polkadot Alpha Builder's Program](https://polkadot.network/development/alpha/) in March 2024. + +In June 2024, we secured 3rd place in the [Polkadot Global Series: North America Hackathon](https://www.polkadotglobalseries.com/north-america/) and 2nd place in the [Polkadot Prodigy Hackathon](https://www.polkadotprodigy.com/) for the Web3 & Tooling track. diff --git a/applications/Nolik.md b/applications/Nolik.md index f2bf354d117..165870b7a93 100644 --- a/applications/Nolik.md +++ b/applications/Nolik.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Nolik -- **Project Name: Nolik - **Team Name: Chainify - **Payment Address:** 0x9aD97d8605F80003106B0ED7DEe330F064674365 (USDT) - **Level: 1 @@ -8,6 +7,7 @@ ## Project Overview :page_facing_up: ### Overview + Nolik is a protocol for delivering digital content for web 3.0. It allows developers to create applications for formal communication that connect people without any form of censorship or third-party control. The protocol design is based on the ServiceLess approach, meaning that no services from third parties are needed for users to communicate. @@ -18,22 +18,22 @@ Blockchain logic will allow users to create programmable messages rules so they For example, users will be able to create a white list (or black list) of senders which will protect them from spam or irrelevant conversations. Another example would be creating rules like accepting messages within a particular block range or if a particular token is attached to the message, etc. - ### Project Details #### The problem we are targeting + The name Nolik stands for No Leak. -We believe that privacy is a fundamental right of every person and we believe that it should be protected. +We believe that privacy is a fundamental right of every person and we believe that it should be protected. Unlike privacy-first messaging applications like Signal or Threema, we offer a tool that allows communication without a need to trust an app itself. It also allows communication without a permission of a third-party which creates a great foundation on which users can rely and build their tools on top of this ecosystem. - #### Technology overview -Nolik uses a combination of blockchain and IPFS technologies. + +Nolik uses a combination of blockchain and IPFS technologies. The user generates an IPFS file with a particular structure on a client-side and broadcasts it to the blockchain network with additional metadata. In addition to required information about the transaction (like signature, sender, recipient, etc.) we provide additional information about the message. We split the blockchain level and messages level by creating a separate set of encryption keys. -Blockchain (identity) keypairs stand for token management and messages (accounts) keypairs stand for message encryption. +Blockchain (identity) keypairs stand for token management and messages (accounts) keypairs stand for message encryption. Users can have several identities (like personal or corporate). At the same time, each identity can have multiple accounts (like email addresses). Each message is encrypted with a public key of the recipient. @@ -43,6 +43,7 @@ You can find how the protocol works in detail below. The protocol is flexible and allows the creation of various data structures which can fit the needs of any app. #### Use case example + Nolik protocol could be used for a media service that protects journalists and whistleblowers from political oppression and technological borders like firewalls, blockings, etc. The protocol guarantees the delivery of the message through the network due to the absence of a single point of failure. A freedom of speech which is guaranteed mathematically. @@ -51,7 +52,7 @@ This means that behind every post there is nothing but a public key. The journalist can prove his identity by publicly attaching the public key to his identity (for example, in social media) and signing some sample data. But if a journalist or a whistleblower would like to hide their identity nothing will stop him from doing that. By default every message is encrypted. -It sounds great but there is a potential scalability downside. +It sounds great but there is a potential scalability downside. To deliver the message to a million people the journalist will have to encrypt the same message million times. The journalist can create a separate account which stands for a channel. That account is a proxy that delivers the message to the audience. @@ -63,29 +64,28 @@ On the channel creation stage, the journalist can add a rule that the channel ac This approach allows them to deliver the message to an unlimited audience and save tons of resources. The same method can be used for creating private or public group conversations. - #### The Protocol Nolik protocol is designed to make trustless communication possible. It provides flexibility for developers so they can build their applications on top of the platform. The protocol allows to: -* Stay protected from a middleware attack -* Communicate without servers or service as a third-party -* Protect messages from unauthorized access with decentralized end-to-end encryption -* Guarantee that the message was sent at a particular date and time -* Have a provable immutability of message content, metadata, and the timestamp information -* Prove that the message was sent by a particular sender -* Prove that the message was sent to a particular recipient or recipients -* Make sure that all recipients received the same message at the same time -* Send messages from multiple senders at the same time -* Verify the sender and be protected from a phishing attack -* Attach tokens (like NFTs) to message -* Use different clients to get access to messages +- Stay protected from a middleware attack +- Communicate without servers or service as a third-party +- Protect messages from unauthorized access with decentralized end-to-end encryption +- Guarantee that the message was sent at a particular date and time +- Have a provable immutability of message content, metadata, and the timestamp information +- Prove that the message was sent by a particular sender +- Prove that the message was sent to a particular recipient or recipients +- Make sure that all recipients received the same message at the same time +- Send messages from multiple senders at the same time +- Verify the sender and be protected from a phishing attack +- Attach tokens (like NFTs) to message +- Use different clients to get access to messages Each message contains two main parts - the transaction data and the IPFS data. The transaction data is additional information that is sent along with required information within a transaction body. -It contains general metadata about the sender and recipient or recipients of the message. +It contains general metadata about the sender and recipient or recipients of the message. This information has a specific purpose and requires specific fields to be provided. The metadata is validated and checked at a sending stage and if something is wrong will be rejected by miners. @@ -99,7 +99,8 @@ However, to solve this issue users within a community can create services that c Another great way to solve this issue would be using FileCoin or similar services to make sure that the recipient will get the message in a longer period. #### Encryption -The message encryption is based on the Diffie-Hellman protocol with the ed25519 curve. + +The message encryption is based on the Diffie-Hellman protocol with the ed25519 curve. To encrypt the message the sender generates a shared secret with the recipient's public key and her private key. At the same time, the recipient generates the same shared secret with the sender's public key and his private key. There is no problem with decrypting the message if the recipient knows the sender's public key. @@ -111,7 +112,7 @@ To do that we use a trick with one-time-use nonce and sender's public key which They are required for the recipient, so he can decrypt the real sender's (sender's) public key and decrypt the message. We will dive into details below. -#### The transaction metadata +#### The transaction metadata Each message contains a specific set of information that is included in the blockchain transaction body. On the other side, recipient or recipients will be able to track the blockchain transactions and decrypt those which were sent to them. @@ -147,19 +148,20 @@ batch: ``` ##### Batch + --- -Each message is encrypted with the recipient's public key based on Diffie-Hellman protocol. +Each message is encrypted with the recipient's public key based on Diffie-Hellman protocol. If there are several recipients the same message is encrypted several times for different recipients. All the versions of the same message should be provided in the batch section. The message should contain nonce, sender, recipient, and data sections. **Nonce** is a section with a one-time generated 24-bit value. It allows making sure that the same message (like "Hi") can not be brute-forced by a malicious third party. -There are two nonce values - the private (encrypted) and the one-time-use one. +There are two nonce values - the private (encrypted) and the one-time-use one. As we mentioned earlier the message is encrypted with the sender's real public key, but for security reasons we encrypt it. -One-time-use nonce is used along with one-time-use public key to encrypt sender's real public key. +One-time-use nonce is used along with one-time-use public key to encrypt sender's real public key. -**Sender** is a section with information about the sender of a particular message. +**Sender** is a section with information about the sender of a particular message. It contains the encrypted public key of a sender. The one-time-use public key is required for the recipient, so he could decrypt the sender's real public key. @@ -175,6 +177,7 @@ It contains encrypted public keys of a recipient. The structure of that file is described below. ##### Nonce + --- The **onetimeuse** value is a one-time public 24-bit nonce that is generated on transaction creation. It is used as salt to sender->ciphertext, sender->blake2hash, verifier->ciphertext, verifier->blake2hash and recipient->blake2hash fields. @@ -186,8 +189,8 @@ It could be used for salting sender->blake2hash, verifier->blake2hash and recipi The **blake2hash** value is salted with the nonce blake2 hash of the nonce. Every recipient will have a unique nonce that can be used to prove message metadata and the content of the message independently from other recipients. - ##### Sender + --- **Sender** is a 32-bit string that represents the sender's public key and account address at the same time. @@ -204,9 +207,11 @@ It can be decrypted only by the recipient. The **blake2hash** value is a hashed sender's public key salted with a one-time-use nonce blake2 hash. The formula looks like this: + ``` H(H(pk), N) ``` + Where "H" is a blake2 hash function, "pk" is the sender's public key and N is a one-time nonce. The sender knows his public keys, and that allows to identify related messages among others. The downside of this approach is that once one knows the sender's public key he will be able to track the account activity. @@ -214,9 +219,11 @@ To fix this the one-time-use nonce can be replaced with private nonce, but in th List of **signatures** is a set of cryptographic proofs (digital signatures) of sender and one-time use private key. Both of the signatures sign the hash of all hashes according to the formula: + ``` H(nH | sH | v(0)H...v(n)H | rH | dH) ``` + Where "H" is a blake 2 hash function, "nH" is nonce blake2hash value, "sH" is sender's blake2hash value, "v(0)H...v(n)H" are concatenated verifiers' blake2hash values, "rH" is recipient's blake2hash value, "dH" is IPFS file hash. ##### Verifiers @@ -236,9 +243,11 @@ It can be decrypted only by the recipient. The **blake2hash** value is salted with one-time-use nonce blake2 hash of a hashed verifier's public key. The formula looks like this: + ``` H(H(pk), N) ``` + Where "H" is a blake2 hash function, "pk" is the verifier's public key and N is a one-time-use nonce. Verifier knows his public keys, and that allows to identify related messages among others. The downside of this approach is that once one knows the sender's public key he will be able to track the account activity. @@ -246,13 +255,15 @@ To fix this the one-time-use nonce can be replaced with private nonce, but in th List of **signatures** is a set of cryptographic proofs (digital signatures) of each verifier and one-time-use public key. Both of the signatures sign the hash of all hashes according to the formula: + ``` H(nH | sH | v(0)H...v(n)H | rH | dH) ``` -Where "H" is a blake 2 hash function, "nH" is nonce blake2hash value, "sH" is sender's blake2hash value, "v(0)H...v(n)H" are concatenated verifiers' blake2hash values, "rH" is recipient's blake2hash value, "dH" is IPFS file hash. +Where "H" is a blake 2 hash function, "nH" is nonce blake2hash value, "sH" is sender's blake2hash value, "v(0)H...v(n)H" are concatenated verifiers' blake2hash values, "rH" is recipient's blake2hash value, "dH" is IPFS file hash. ##### Recipient + --- **Recipient** is a 32-bit string that represents the recipient's public key and account address at the same time. @@ -262,22 +273,24 @@ It can be decrypted only by sender and recipient. The **blake2hash** vvalue is a blake2 hash of a hashed recipient's public key salted with one-time-use nonce. The formula looks like this: + ``` H(H(pk), N) ``` + Where "H" is a blake2 hash function, "pk" is the recipient's public key and N is a one-time-use nonce. The recipient knows his public keys, and that allows to identify related messages among others. The downside of this approach is that once one knows the recipient's public key he will be able to track the account activity. To fix this the one-time-use nonce can be replaced with private nonce, but in this case, the recipient will have to decrypt every message in the blockchain. - ##### Data + --- Data is a section with an IPFS hash of a file that contains encrypted message information in key-value format. We will discuss the structure of an IPFS file below. - #### The IPFS data file + --- The data file is a text file with a specific data structure. It contains encrypted data which can be decrypted only by the sender and recipient of a message. @@ -297,16 +310,16 @@ data: ``` #### Key + --- -The **ciphertext** value is an encrypted name of a particular field. +The **ciphertext** value is an encrypted name of a particular field. It can be decrypted only by sender and recipient. The **blake2hash** value is salted with the private nonce blake2 hash of data content. - #### PoC and prior work -We have been working on decentralized messaging apps for the last several years. +We have been working on decentralized messaging apps for the last several years. During this time the protocol became much more solid and stable. Here are some related links: @@ -317,12 +330,11 @@ Here are some related links: This is the latest open-source version of the messenger. The protocol is more or less the same, but to run the messaging service one has to use centralized servers to increase the user experience. - The **latest** version I've been working on is not open-source because it was a custom build for an external company, but here is a video demo of how the messenger works: >[XYZ Messenger Demo (EN) -- 5m 38s](https://youtu.be/HSMjikDiheY) -This technology has been used in production at a nonprofit organization [HelpTeens](https://helpteens.ru) in Saint-Petersburg that provides free online psychological support for teenagers. +This technology has been used in production at a nonprofit organization [HelpTeens](https://helpteens.ru) in Saint-Petersburg that provides free online psychological support for teenagers. We used Nolik to protect kids' privacy and keep their secrets safe. It worked perfectly, but we had to stop using the technology due to legal restrictions. A new set of legal rules obligates any company to disclose the decryption keys to authorities and we had nothing to disclose. @@ -350,7 +362,7 @@ The technology has changed but the core principles are still the same. >[Nolik DB Demo -- 1m 11s](https://youtu.be/PyueRPY4fHc) This is an experiment from one of the hackathons. -I applied the Nolik protocol to build a decentralized database that allows the storage of structured data using SQL syntax. +I applied the Nolik protocol to build a decentralized database that allows the storage of structured data using SQL syntax. #### Non-goals @@ -364,7 +376,6 @@ Although Nolik is designed to be an independent product, the secure platform wit For example, apps will be able to exchange secrets like private keys, send tokens or a WASM code. That might be one of the possible benefits for the Polkadot community, but we will know if there is any value only by talking to users. - ## Team :busts_in_silhouette: ### Team members @@ -377,14 +388,15 @@ That might be one of the possible benefits for the Polkadot community, but we wi - **Contact Email:** aboziev@gmail.com ### Legal Structure + No legal entity yet ### Team's experience -#### Amir Boziev +#### Amir Boziev Since 2018 I've been involved in various projects in different domains including edTech, private messaging, data security, social good, and others. -I've increased my expertise in product development, marketing, and programming. +I've increased my expertise in product development, marketing, and programming. Worked as a researcher in blockchain tech to find a product-market-fit for this amazing technology which I'm passionate about. For the last five years, I've been learning how to make successful products. @@ -393,12 +405,12 @@ One of them is growing. Right now I am learning [Game Thinking Mechanicks](http://gamethinking.io) to make better products. Previously worked as a Director of blockchain products and strategy at Latoken. -I've been working with amazingly talented people on product management and the development of both decentralized and centralized crypto exchanges. -We also have been working on fundamental research and development of a framework that simulates the behavior of a blockchain on a network level. +I've been working with amazingly talented people on product management and the development of both decentralized and centralized crypto exchanges. +We also have been working on fundamental research and development of a framework that simulates the behavior of a blockchain on a network level. We've analyzed the most popular consensus algorithms (PoW, PoS, dPoS BFT, etc.) and blockchain platforms (Bitcoin, Ethereum, Cordana, Ripple, Waves, Hashgraph, etc.). -I also was fortunate to be a speaker and moderator of technical panel discussions at Blockchain Economic Forum in Singapore and San-Francisco (cross-chain communication, mining, security, scalability, etc.) and to work with the Moscow blockchain community as head of educational Chain{Dev} project. +I also was fortunate to be a speaker and moderator of technical panel discussions at Blockchain Economic Forum in Singapore and San-Francisco (cross-chain communication, mining, security, scalability, etc.) and to work with the Moscow blockchain community as head of educational Chain\{Dev} project. Full-stack web developer, Python, JS, Docker, SQL, Blockchain. Rust experience: 3+ months, but moving fast. @@ -414,17 +426,16 @@ Please also provide the GitHub accounts of all team members. If they contain no ### Team LinkedIn Profiles -- https://www.linkedin.com/in/amrbz +- https://www.linkedin.com/in/amrbz ## Development Status :open_book: -* [XYZ Messenger](https://docs.google.com/document/d/1Vxieh7b6wTQZoHpBQQTC5bH58kwcYlF0wm8yh0acXCI/edit?usp=sharing) +- [XYZ Messenger](https://docs.google.com/document/d/1Vxieh7b6wTQZoHpBQQTC5bH58kwcYlF0wm8yh0acXCI/edit?usp=sharing) -* [Rhizome](https://docs.google.com/document/d/1nbqO-ZHKTltqS7a10MYHKIetiFPd_NS6danfV7rGp1I/edit?usp=sharing) +- [Rhizome](https://docs.google.com/document/d/1nbqO-ZHKTltqS7a10MYHKIetiFPd_NS6danfV7rGp1I/edit?usp=sharing) Those are research documents that lead me to this project. - ## Development Roadmap :nut_and_bolt: ### Overview @@ -451,7 +462,6 @@ This milestone will allow the operation of a local dev chain. | 2. | Substrate module: Message Validation | We will create a Substrate module that will validate the message on sending stage to accept or reject it | | 3. | Substrate chain | Both modules of our custom chain will allow users to set up account rules and validate incoming messages on whether the senders have a right to send a message or not. In case of a rejected transaction user will get a related error message| - ### Milestone 2 — Develop CLI tools This milestone will allow the usage of CLI tools, which are going to be written in Rust language. They will allow users to interact with the network by composing, sending, and accepting messages. @@ -472,27 +482,25 @@ This milestone will allow the usage of CLI tools, which are going to be written | 3. | CLI: get | We will create a CLI tool that will allow to download and read received messages if any | | 4. | CLI | CLI tools will allow users to compose messages, send them to recipients and read incoming messages on request | - ## Future Plans ### Short-term -* Apply to the Substrate Builders Program. -* Develop the PoC blockchain core with CLI tools -* Make customer research and validate product ideas -* Launch a public testnet and build a Messaging app - +- Apply to the Substrate Builders Program. +- Develop the PoC blockchain core with CLI tools +- Make customer research and validate product ideas +- Launch a public testnet and build a Messaging app ### Long-term -* Close seed funding round and form a team -* Apply to W3F L3 grant program -* Convert to mainnet -* Build a messaging app +* Close seed funding round and form a team +- Apply to W3F L3 grant program +- Convert to mainnet +- Build a messaging app ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** Personal recommendation of my friends: -* https://github.com/kmadorin -* https://github.com/CryptoBadBoy W3F grant program alumni (Fratcapp) \ No newline at end of file +- https://github.com/kmadorin +- https://github.com/CryptoBadBoy W3F grant program alumni (Fratcapp) diff --git a/applications/NuLink.md b/applications/NuLink.md index bf1386cd788..baeb8de311d 100644 --- a/applications/NuLink.md +++ b/applications/NuLink.md @@ -1,5 +1,5 @@ -# Open Grant Proposal -* **Project:** NuLink +# NuLink + * **Proposer:** Pawn * **Payment Address:** 0xf7410438ead9e89EEd5ca6e61a11E862C297ca0e diff --git a/applications/OfflineElectionTool.md b/applications/OfflineElectionTool.md new file mode 100644 index 00000000000..4f5ca6317a3 --- /dev/null +++ b/applications/OfflineElectionTool.md @@ -0,0 +1,233 @@ +# Offline Election Tool + +- **Team Name:** Starks +- **Payment Details:** + - **Payment**: 0x4c2f3896E60B79ab3821cad311bD4c30Ae0a4693 (USDC) . +- **[Level](https://grants.web3.foundation/docs/Introduction/levels):** 1 + + +## Project Overview :page_facing_up: + +This application is in response to the open RFP [offline-election-tool](https://grants.web3.foundation/docs/RFPs/offline_election_tool) + +### Overview + +- Goal: Predict on-chain validator elections with accuracy and flexibility. +- This project is a simulation tool designed to accurately replicate the outcome of the on-chain validator election algorithm used by staking-based blockchain networks. It allows users to predict which validators will be elected, the stake distribution, and nomination assignments at any given point—whether during an actual election. The tool supports configurable parameters (such as custom voters and candidates), includes support for all election algorithms, and is accessible via both CLI and a RESTful API. +- The tool is directly relevant to the Nominated Proof-of-Stake (NPoS) system used by Polkadot, Kusama, and other Substrate-based networks. It mimics the behavior of Substrate’s election algorithms (e.g., Phragmén-based elections), leveraging staking data and governance parameters to simulate active set selection. It serves as a companion tool for networks built with Substrate to test, audit, and optimize validator nomination strategies off-chain. +- Our team is passionate about improving the transparency, accessibility, and decentralization of staking ecosystems. As participants in decentralized validator programs, we found existing tools outdated and lacking in flexibility. By creating this robust, customizable election simulator, we aim to empower nominators, validators, and researchers to better understand validator elections and make data-driven decisions—ultimately improving decentralization in the validator selection process. + +### Project Details +#### UI Mockups / Designs +As this tool is primarily CLI- and API-based, no user interface mockups are required at this stage. However, the API will be designed to support potential integration with front-end dashboards or explorers in the future. +- The predicted active validator set. + +#### Data Models / API Specifications +#### Core Input Parameters (JSON Schema format): + +```json +{ + "voters": [ + { + "account_id": "AccountId", + "stake": "u128", + "targets": ["ValidatorId"] + } + ], + "candidates": [ + { + "account_id": "ValidatorId", + "bond": "u128" + } + ], + "active_set_size": 100, + "election_algorithm": "sequential-phragmen | phragmen | approval-voting", + "snapshot_block": "optional" +} +``` + +#### Core API Endpoints (REST): + +- POST /simulate: Runs the election with custom parameters. +- GET /defaults: Retrieves live chain snapshot (voters, candidates, stake) from current or historical block. +- POST /validate-results: Compares tool output with on-chain election results at a given block height. + +#### API Output Example: + +```json +{ + "active_validators": [ + { + "account_id": "ValidatorId", + "total_stake": "u128", + "nominators": ["AccountId"] + } + ] +} +``` + +#### Technology Stack + +- Rust – Core election logic will be ported or reused from Substrate's implementation to ensure accuracy. +- Node.js – Wrapper logic for scripting and CLI interaction. +- Rocket (Rust) – REST API server for running simulations via HTTP. +- Subxt / Polkadot.js API – To fetch live or historical staking data from a Substrate-based chain. +- Docker – For containerization and easy deployment. + +#### Core Component Overview + +##### Election Engine +Implements core logic for simulating elections using Substrate's election algorithms (especially Phragmén and Sequential Phragmén). + +##### Data Loader +Fetches on-chain staking data (candidates, nominators, bonded amounts) using RPC or snapshot files. + +##### Simulation Interface (CLI + API) +- CLI for local usage and automation. +- API for remote usage or frontend integration. + +##### Validation Module +Compares predicted results with on-chain results for verification and debugging. + +#### Prior Work / PoC + +- We already have access to an earlier version of a validator election script. While it demonstrates the feasibility of simulating elections, it is: +- Tightly coupled with a single chain’s staking logic. +- Inaccurate for newer election algorithms or edge cases (e.g., non-existent accounts). +- Lacking API support and customization flexibility. + +#### Additional information + +- **Relation to polkadot-staking-miner (https://github.com/paritytech/polkadot-staking-miner/issues/1050):** + Our planned approach largely coincides with the discussion in the referenced issue. + We intend to base the solution on `polkadot-staking-miner`, extending it with offline election prediction capability and exposing parameters for customization. + +- **Election algorithm if unspecified:** + If the user does not specify an algorithm, the tool will default to the election algorithm currently used by the Polkadot chain (Phragmen). + This ensures consistency with on-chain elections. + +- **Handling missing snapshot block in Off Phase:** + If no snapshot block is specified and the tool is executed during the Off Phase, it will fallback to the latest available chain state to generate results. + This allows predictions to remain useful without requiring manual input. + +- **Compatibility after Asset Hub migrations / staking-async:** + We are aware that the new staking miner only works with staking-async after the Asset Hub migrations. + Our tool is designed with this in mind to ensure smooth operation post-migration. + +- **Output requirements (nominator allocation + stake):** + The output will include: + 1. List of nominators allocated to each validator + 2. Specific stake amounts allocated. + We consider this essential for the usefulness of the tool. + +This project will build upon that foundation, reusing logic where valid, but heavily refactoring and extending it to meet modern use cases. + +### Ecosystem Fit + +- A simulation tool that predicts validator elections in Substrate-based networks like Polkadot and Kusama. +- Targets parachain teams, nominators, validator operators, staking dashboards, and researchers. +- Solves the need for accurate, customizable off-chain validator election prediction. +- Identified through community feedback, Kusama DNP requirements, GitHub issues, and forum discussions. +- Existing tools like the old Web3 script are outdated; dashboards lack simulation features.Our tool is distinct by offering full API/CLI access, support for all election algorithms, and hypothetical input handling. + +## Team :busts_in_silhouette: + +> [!IMPORTANT] +> Please note that the data provided in this section is for administrative and informational purposes only. All beneficiaries of a grant must also be listed in the KYC/KYB process during the application phase. See our [FAQ](https://grants.web3.foundation/docs/faq#what-is-kyckyb-and-why-do-i-have-to-provide-this-data) for more info. + +### Team members + +- **Team lead:** [Shubham Gupta](https://github.com/s-h-ubham) +- **Team member:** [Ipsa Gupta](https://github.com/Ipsa11?tab=repositories) +- **Team member:** [Arunjot Singh](https://github.com/arunjot12?tab=repositories) + +### Contact + +- **Contact Name:** Karan Chopra +- **Contact Email:** karan.chopra@antiersolutions.com + +### Legal Structure + +- **Registered Address:** C-208, Phase 8B, Industrial Area, Sector 74, Sahibzada Ajit Singh Nagar, Punjab 160059 +- **Registered Legal Entity:** AntLabs India Pvt. Ltd. + +### Team's experience + +We are a skilled and dedicated group of professionals who possess extensive experience working with the Substrate ecosystem. Our team members have successfully completed numerous projects related to Substrate development, including building custom blockchains, implementing governance mechanisms, and designing smart contract for intuitive dApp functionalites. We understand the importance of technical partnerships in fostering innovation and growth within the blockchain industry. We are confident that our knowledge of the Substrate framework and its capabilities will enable us to contribute significantly to the development and expansion of Polka's ecosystem. + +Stack exchange profiles of some of our team members: +1. https://substrate.stackexchange.com/users/3414/ipsa-gupta +2. https://substrate.stackexchange.com/users/354/shubham-gupta +3. https://substrate.stackexchange.com/users/2372/arunjot-singh + +## Development Status :open_book: + +[offline-election-tool](https://grants.web3.foundation/docs/RFPs/offline_election_tool) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 weeks +- **Full-Time Equivalent (FTE):** 1 +- **Total Costs:** 5000 USD + +### Milestone 1 Core Election Simulation Tool + +- **Estimated duration:** 2 weeks +- **FTE:** 1 +- **Costs:** 2,500 USD + + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense. | +| **0b.** | Documentation |Inline code documentation and a tutorial explaining how to simulate an election with default or custom inputs via CLI. | +| **0c.** | Testing and Testing Guide | Unit tests for the election logic; guide on how to run and interpret the results. | +| **0d.** | Docker | Dockerfile to build and run the CLI simulator locally. | +| 1. | Core Election Engine | Updated version of the existing election script with support for accurate simulation of on-chain validator election logic using Phragmén algorithm. | +| 2. | Custom Inputs Support | Allows passing custom active set size, voters, candidates, and their stakes via JSON input. | + + +### Milestone 2 Support for Hypothetical/Off-Chain Accounts + +- **Estimated Duration:** 1 week +- **FTE:** 1 +- **Costs:** 1,250 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense. | +| **0b.** | Documentation |Examples and guide on how to include hypothetical or non-existent accounts in the simulation. | +| **0c.** | Testing and Testing Guide | Unit tests covering edge cases with invalid or off-chain accounts. | +| **0d.** | Docker | Docker image updated to support all new input types. | +| 1. | Hypothetical Account Simulation | Extend simulation engine to support voters or candidates that do not exist on-chain or lack bonded amounts. | + +### Milestone 3 API Interface + +- **Estimated Duration:** 1 week +- **FTE:** 1 +- **Costs:** 1,250 USD + + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense. | +| **0b.** | Documentation |API documentation and usage examples using tools like Postman or curl. | +| **0c.** | Testing and Testing Guide | Integration tests for all API endpoints and a guide to test via API calls. | +| **0d.** | Docker | Dockerfile to run the RESTful API server exposing the simulation endpoints. | +| **0e.** | Article | A blog post or technical article describing how the election simulation works, how to use the tool via API, and its applications for nominators and validator programs. | +| 1. | API functionality | Implement API functionality to set parameters and expose results. | + + +... + + +## Future Plans + +We intend to maintain and enhance the Offline Election Tool through ongoing contributions from our core team, and potentially through future grants or ecosystem support from stakeholders who benefit from accurate validator election simulations, such as staking providers and parachain teams. In the short term, we will open-source the tool, provide comprehensive documentation, and promote it within the Polkadot and Kusama staking communities to gather early feedback and improve usability. Long-term, our goal is to make the tool a reliable reference for off-chain validator election predictions, keeping it aligned with ongoing changes in election logic and expanding its utility for ecosystem participants like governance platforms, dashboards, and staking automation tools. + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** A friend recommended diff --git a/applications/Omniverse DLT.md b/applications/Omniverse DLT.md new file mode 100644 index 00000000000..f9196c6d58d --- /dev/null +++ b/applications/Omniverse DLT.md @@ -0,0 +1,260 @@ +# Omniverse DLT + +> This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines (except for the title)! Lines starting with a `>` (such as this one) should be removed. Please use markdown instead of HTML (e.g. `![](image.png)` instead of ``). +> +> See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. +- **Team Name:** Omniverse Labs (Formerly Dante Team) +- **Payment Address:** 14yr1tovebKbRbxggduV1vbTPtRQtgzTXh9tdZ34w3pGbc4W (Polkadot (Statemint) USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +> :exclamation: *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.* +## Project Overview :page_facing_up: + +- [Previous Proposal: Dante Network](https://github.com/w3f/Grants-Program/blob/master/applications/Dante_Network.md) + - [Milestone 1 Delivery](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/Dante_Network_milestone_1.md) + - [Milestone 2 Delivery](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/Dante_Network_milestone_2.md) + +As we know, Dante Network is a protocol that serves heterogeneous consensus and can help Polkadot expand the outer edge. In the previous work, Dante has completed its basic technology abilities. Now we come to the **technical form** of the token, and we have mentioned in the [future work](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/Dante_Network_milestone_2.md#future-work) of the last delivery that as an infrastructure for multi-chains, the first thing is that the token of Dante would be used on all chains we support. More importantly, we want the token of Dante to be treated as **a whole**, instead of being divided into different parts as current assets bridges did. +So in our research, we innovatively found a more suitable Token model - Omniverse DLT. A more interesting thing is that, Omniverse DLT can be used not only for Dante, but also for all kinds of assets on Polkadot/Kusama. We will present the details in the [Ecosystem Fit](#ecosystem-fit) section. + +### Overview +#### Tag Line +Omniverse DLT, **O-DLT** for short. + +#### Brief description +The Omniverse DLT is a new **application-level** token protocol built **over** multiple existing L1 public chains, enabling asset-related operations such as transfers and receptions running **over** different consensus spaces **synchronously and equivalently**. + +The core meaning of **Omniverse** is that ***The legitimacy of all on-chain states and operations can be equivalently verified and recorded simultaneously over different consensus spaces, regardless of where they were initiated.*** + +O-DLT works at an **application level**, which means everything related is processed in **smart contracts** or **pallets**. **Nothing** relates to the native transactions of a single chain. + +#### Relates to Polkadot +In this application, three forms of implementation of the Omniverse DLT will be provided. +- It will be implemented as a `substrate pallet`, which can be used as a basic component in any `Substrate Parachain` project. The omniverse assets part will derive from `pallet assets`. +- It will be implemented as `ink!` smart contracts, which is an upgrade to the current FT/NFT smart contract for `Substrate Ink!`. +- It will be implemented as `solidity` smart contracts (for Moonbeam), which is an upgrade to the current ERC20/ERC721 smart contract. **This is not part of this grant, but we will still provide it**. + +Besides being used for Dante's token, everyone in Polkadot can use O-DLT as a component to build their own project if they want their tokens to be global. + +- In addition, we will implement a swap platform especially for different Omniverse tokens, which will be implemented as a `substrate pallet`. + +#### Why we are intrested in it +As an infrastructure serving multiple chains, we definitely want Dante's token to be accessed anywhere. However, we do not believe that the asset-bridge paradigm is appropriate. +- We want Dante's token to be treated as a whole instead of being devided into different parts on different public chains. O-DLT can get it. +- When one chain breaks down, we don't want to lose our assets along with it. Assets-bridge paradigm cannot provide a guarantee for this. O-DLT can provide this guarantee even if there's only one chain that works. +- Not just for Dante's token, we are willing to help other projects make their token omniverse if they need it. O-DLT is such a new kind of asset paradigm at the application-level. + +### Project Details +#### Architecture +![image](https://user-images.githubusercontent.com/83746881/211817046-8c42543b-0dcc-49d3-8219-b1d2af06368b.png) +

          Figure.1 Architecture

          +Generally, this project is composited with the O-DLT components, a swap component for Omniverse tokens, and the off-chain synchronizers. + +#### Components +- O-DLT is implemented as a `substrate pallet` and `ink! smart contract` on Polkadot, and as smart contracts on other chains(EVM chains for instance). A special cryptographic commitment is used to make a verification when a change in ownership of the token occurs, which can be verified in an equivalent approach on different tech stacks of different blockchains. The special commitment is unfakeable and non-deniable. Moreover, the transfer of Omniverse tokens happened on an Omniverse Account Protocol, and be guaranteed by an Omniverse Transaction Protocol. + - The implementation of the Omniverse Account is not very hard, and we temporarily choose a common elliptic curve secp256k1 to make it out, which has been already supported by many blockchains. + - The `Omniverse Transaction` guarantees the ultimate consistency of omniverse transactions(**o-transaction** for short) across all chains. + - We will define an **application-level** data structure to describe omniverse transactions, which can be treated in the same way in different tech stacks. The [example code of the *TransactionData*](https://github.com/Omniverse-Web3-Labs/omniverse-swap/blob/69cebda3e567df1c807a9cb0cda180528f4de091/pallets/omni-protocol/src/types.rs#L60) will be similar to the following: + ```Rust + #[derive(Clone, PartialEq, Eq, Debug, Encode, Decode, TypeInfo)] + pub struct OmniverseTransactionData { + pub nonce: u128, // Global o-transaction identifier + pub chain_id: u32, // The chain where the o-transaction is initiated + pub Initiator_address: Vec, // The identifier of an Omniverse Token. This is globally unique + pub from: [u8; 64], // The Omniverse account transfer from + pub op_type: u8, // The operation type(mint, burn, transfer, ...) + pub op_data: Vec, // The operation data, `to` account for instance + pub amount: u128, // The amount of assets + pub signature: [u8; 65], // The signature of the above informations + } + ``` + - The `nonce` is very important, which is the key point to **synchronize** the states globally, which will be described later. + - The `nonce` appears at two places, one is `nonce in o-transaction` data as above, the other is `account nonce` maintained by on-chain O-DLT pallets/smart-contracts([example codes](https://github.com/Omniverse-Web3-Labs/omniverse-swap/blob/69cebda3e567df1c807a9cb0cda180528f4de091/pallets/omni-protocol/src/lib.rs#L61)). + - The `nonce in o-transaction` data will be verified according to the `account nonce` managed by on-chain `Omniverse DLT` pallets/smart-contracts. Some [example codes](https://github.com/Omniverse-Web3-Labs/omniverse-swap/blob/69cebda3e567df1c807a9cb0cda180528f4de091/pallets/omni-protocol/src/functions.rs#L39) can be found here. + - The core operations of the O-DLT are `omniverse_transfer`, `omniverse_mint`, and `omniverse_burn`, in which the first thing is verifying the signature of the o-transaction data. Then the operation will be added to a pre-execution cache, and **wait for a fixed time** until being executed. The waiting time will be able to be settled by the deployer and this will be determined until fully tested, in addition, we will provide the least recommended time. The off-chain synchronizer will carry the o-transaction data to other chains. If another o-transaction data with the same nonce and the same sender account is received within the waiting time, and if there's any sector different, a malicious thing happens and the related account will be punished. We provide some example codes [here](https://github.com/Omniverse-Web3-Labs/omniverse-swap/blob/69cebda3e567df1c807a9cb0cda180528f4de091/pallets/assets/src/functions.rs#L877) and [here](https://github.com/Omniverse-Web3-Labs/omniverse-swap/blob/69cebda3e567df1c807a9cb0cda180528f4de091/pallets/assets/src/functions.rs#L932) to explain how it works. + - The commitment verification protocol is an underly mechanism, which is a newest research result of Dante. It provides an absolute cryptographic way to make verifications for omniverse operations, in which malicious things could be found out determinedly. + +- The OSC(Omniverse Swap Component) is a direct swap platform for exchanges of Omniverse tokens. The calculation of the o-transaction amount is done by an O-AMM model we create. The details of the underlying mechanisms can be found in the [Principle of Omniverse-AMM](https://github.com/Omniverse-Web3-Labs/Omniverse-DLT-Introduction/blob/main/docs/Principle%20of%20Omniverse%20AMM.md). An omniverse swap operation can be initiated based on the O-DLT. OSC is implemented as a substrate pallet, and a mechanism similar to *abstract account smart contract* will be made out to operate an abstract account for the omniverse swap along with the substrate consensus. + +- The bottom is the off-chain synchronizer layer. The synchronizer is a very light off-chain procedure, and it just listens to the Omniverse events happening on-chain and makes the information synchronization. As everything in Omniverse paradigm is along with a commitment(signature for instance) and is verified by cryptographic algorithms, there's no need to worry about synchronizers doing malicious things. So the off-chain part of O-DLT is indeed trust-free. Everyone can launch a synchronizer to get rewards by helping synchronize information. The detailed steps can be found in the next chapter. + +#### Implementation & Example +- The O-DLT has the following features: + - The omniverse token(o-token for short) based on O-DLT deployed on different chains is not separated but as a whole. If someone has one o-token on Polkadot, he will have an equivalent one on Ethereum and other chains at the same time. + - The state of the tokens based on O-DLT is synchronous on different chains. If someone sends/receives one token on Polkadot, he will send/receive one token on Ethereum and other chains at the same time. + - The workflow of O-DLT is as below. ***Note that in an Omniverse token o-transaction the user only needs to initiate a sending transaction on whatever blockchain he prefers, and the rest things are all processed by the underlying protocols.*** +

          Figure.2 An Example

          + + ![image](https://user-images.githubusercontent.com/83746881/211828536-bca481a5-588e-49ec-818b-0b5d6685ffd7.png) + - Suppose a common user `A` and the related operation `account nonce` is $k$. + - `A` initiate an omniverse transfer operation on Near by calling `omniverse_transfer`. The current `account nonce` of `A` in O-DLT deployed on Near is $k$ so the valid value of `nonce in o-transaction` needs to be $k+1$. + - The O-DLT smart contracts on Near verify the signature of the o-transaction data at an **application level**. If the verification for the signature and data succeeds, the o-transaction data will be published. The verification for the data includes: + - whether the amount is valid + - and whether the `nonce in o-transaction` is 1 larger than the `account nonce` maintained by the on-chain O-DLT + - Now, `A`'s newest submitted `nonce in o-transaction` on Near is $k+1$, but still $k$ on Polkadot, Ethereum, and Flow. + - The off-chain synchronizers find the new published o-transaction, and they will find the `nonce in o-transaction` is larger than the related `account nonce` on other chains. + - These synchronizers will rush to carry this message, because whoever submits to the destination chain first will get a reward. There's no will for independent synchronizers to do evil, because they just carry `A`'s o-transaction data. + - Finally, the O-DLT smart contracts/pallets deployed on other chains will all receive the o-transaction data, verify the signature and execute it when the **waiting time is up**. After execution, the underlying `account nonce` will add 1. Now all the `account nonce` of account `A` will be $k+1$. + +We have provide a detailed [proof for the **ultimate consistency**](https://github.com/Omniverse-Web3-Labs/o-amm/blob/main/docs/Proof-of-ultimate-consistency.md) for better understanding of the **synchronization** mechanisms. + +#### Attack Vector Analysis +According to the [above](#implementations), there are two roles: +- **common users** who initiate a o-transaction (at the application level) +- and **synchronizers** who just carry the o-transaction data if they find differences between different chains. + +The two roles might be where the attack happens: +- **Will the *synchronizers* cheat?** + - Simply speaking, it's none of the **synchronizer**'s business as **they cannot create other users' signatures** unless some **common users** tell him, but at this point, we think it's a problem with the role **common user**. + - The **synchronizer** has no will and cannot do evil because the transastion data they carry is verified by the related **signature** of others(a **common user**). + - The **synchronizers** will be rewarded as long as they submit a valid o-transaction data, and *valid* only means that the signature and the amount are both valid even if the `nonce in o-transaction` is **invalid**. This will be detailed explained later when analyzing the role **common user**. + - The **synchronizers** will do the delivery once they find differences between different chains: + - If the current `account nonce` on one chain is smaller than a published `nonce in o-transaction` on another chain + - If the transaction data related to a specific `nonce in o-transaction` on one chain is different from another published o-transaction data with the same `nonce in o-transaction` on another chain + + - **Conclusion: The *synchronizers* won't cheat because there's no benifits and no way for them to do so.** + +- **Will the *common user* cheat?** + - Simply speaking, **yes they will**, but fortunately, **they can't succeed**. + - Suppose current `account nonce` of a **common user** `A` is $k$ on all chains. + - Common user `A` initiates an o-transaction on a Parachain of Polkadot first, in which `A` transfer `10` o-tokens to an o-account of a **common user** `B`. The `nonce in o-transaction` needs to be $k+1$. After signature and data verification, the o-transaction data(`ot-P-ab` for short) will be published on Polkadot. + - At the same time, `A` initiates an o-transaction with the same nonce $k+1$ but different data(transfer `10` o-tokens to another o-account `C`) on Ethereum. This o-transaction(named as `ot-E-ac`) will pass the verification on Ethereum first, and be published. + - At this point, it seems `A` finished a ***double spend attack*** and the O-DLT states on Polkadot and Ethereum are different. + - **Response strategy**: + - As we mentioned above, the synchronizers will deliver `ot-P-ab` to the O-DLT on Ethereum and deliver `ot-E-ac` to the O-DLT on Polkadot because they are different although with the same nonce. The synchronizer who submits the o-transaction first will be rewarded as the signature is valid. + - Both the O-DLTs on Polkadot and Ethereum will find that `A` did cheating after they received `ot-E-ac` and `ot-P-ab` respectively as the signature of `A` is non-deniable. + - We mentioned above that the execution of an o-transaction will not be done immediately and instead there needs to be an fixed waiting time. So the `double spend attack` caused by `A` won't succeed. + - There will be many synchronizers waiting for delivering o-transactions to get rewards. So although it's almost impossible that a **common user** can submit two o-transactions to two chains, none of the synchronizers deliver the o-transactions successfully because of a network problem or something else, we still provide a solution: + - The synchronizers will connect to several native nodes of every public chain to avoid the malicious native nodes. + - If it indeed happened that all synchronizers' network break, the o-transaction will be synchronized when the network recovered. If the waiting time is up and the cheating o-transaction has been executed, we will revert it from where the cheating happens according to the `nonce in o-transaction` and `account nonce`. + - `A` will be punished(lock his account or something else, and this is about the tokenomics, so we won't discuss it according to [application-template.md](./application-template.md#L40)). + - **Conclusion: The *common user* will cheat but won't succeed.** + +#### Demos +- We have provide a [demo video](https://o20k.s3.us-west-2.amazonaws.com/omniverse-swap.mp4) to explain how O-DLT works. +- We also provide a [manually trying tutorial](https://github.com/Omniverse-Web3-Labs/Omniverse-DLT-Introduction/blob/main/docs/README.md) + +### Ecosystem Fit + +Intuitively but non-rigorously, we consider a single public chain as a country, and any country wants their currency to be common in other countries as well. +We are trying to provide an infrastructure to help all assets on Polkadot/kusama be global without being divided into different parts as current assets-bridges did, and the breaking of any other chain will not influence the assets on Polkadot/kusama ecosystem. +We will make the O-DLT an open source-protocol so that everyone in Polkadot/Kusama ecosystem can use it to publish their own omniverse tokens all by themselves. We will provide the following things to Polkadot/Kusama: +- O-DLT `substrate pallets` +- O-DLT `ink! smart contracts` +- O-DLT `solidity smart contracts` for Moonbeam. **This is not part of this grant and we will still provide it**. +- O-Swap `substrate pallets` + +The above components can be uses as single component for all developers of Polkadot/kusama. + +## Team :busts_in_silhouette: + +### Team members + +- Shawn Zheng + - GitHub: https://github.com/xiyu1984 + - Email: xiyuzheng1984@gmail.com +- Members: + - George Huang + - GitHub: https://github.com/virgil2019 + - Email: hht2015ily@gmail.com + - Kay Lin + - GitHub: https://github.com/kay404 + - Email: kay20475@gmail.com + +### Contact + +- **Contact Name:** Shawn Zheng +- **Contact Email:** xiyuzheng1984@gmail.com +- **Website:** https://github.com/Omniverse-Web3-Labs + +### Legal Structure + +- **Registered Address:** 5001 BEACH ROAD #07-37, Golden Mile Complex, Singapore +- **Registered Legal Entity:** Kvanace Technology Foundation Ltd. + +### Team's experience + +We are Dante Network team and our team is composed of several skilled Web3 geeks, and some of us have more than 10 years of technology working experience. +We have got several hackathon rewards, especially the first prize in the Polkadot Asian Hackathon in 2022 summer. +We have finished the first step of Dante Network granted by Web3 Foundation. Details can be found [here](https://github.com/w3f/Grants-Program/blob/master/applications/Dante_Network.md) and [here](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/Dante_Network_milestone_2.md). + +### Team Code Repos + +To be more clearly, we have created a new organization to manage the related code: +- https://github.com/Omniverse-Web3-Labs/ + +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/xiyu1984 +- https://github.com/virgil2019 +- https://github.com/kay404 + +## Development Status :open_book: + +Before apply for this grant, we have done some neccessary researches and built some prototypes to verify them. + - [Simulation of Omniverse DLT on Substrate Pallets](https://github.com/Omniverse-Web3-Labs/omniverse-swap) + - [Off-Chain Simulation of O-AMM mathematic model](https://github.com/Omniverse-Web3-Labs/o-amm) + - [On-Chain Simulation of O-AMM mathematic model](https://github.com/Omniverse-Web3-Labs/O-AMM-ParaSim) + +After the simulation, we believe that the Omniverse DLT is achievable on Polkadot and other chains. + +## Development Roadmap :nut_and_bolt: +### Overview + +- **Total Estimated Duration:** 4 months +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 30,000 USD. + +### Milestone 1 — O-DLT: Substrate Pallet + +- **Estimated duration:** 2 month +- **FTE:** 3 +- **Costs:** 15,000 USD + +> :exclamation: **The default deliverables 0a-0d below are mandatory for all milestones**, and deliverable 0e at least for the last one. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | - We will provide docs to explain how O-DLT works in a high-level
          - We will provide dev docs to explain how to develop an O-DLT component in Substrate Pallet
          - We will provide tutorial docs to explain how to use it | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Article | We will publish an **article** that explains what was done/achieved in this milestone as part of the grant. | +| 1. | Substrate module: omniverse assets | We will create a Substrate module that will manage the Omniverse tokens, which will be derived from standard `pallet assets` | +| 2. | Substrate module: omniverse protocol | We will create a Substrate module that will manage the underlying omniverse functions like omniverse account, omniverse signature, omniverse verification, etc. | +| 3. | Substrate chain | Modules omniverse assets, protocol of our custom chain will interact in such a way that can make creation, omniverse mint, burn, and transferring for o-tokens | +| 4. | Off-Chain Tools: Operate the o-tokens | We will provide off-chain tools to operate o-tokens for both `Substrate Pallets` | + +### Milestone 2 — Ink! tech stack and Omniverse Swap + +- **Estimated Duration:** 2 month +- **FTE:** 3 +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | - We will provide docs to explain how the Omniverse Swap based on O-DLT works in a high-level
          - We will provide dev docs to explain how to develop an O-DLT component in `Ink!` smart contract
          - We will provide tutorial docs to explain how to use the omniverse swap | +| **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) to run Synchronizers along with the documentation of the setup. | +| 0e. | Article | We will publish an **article** that explains what was done/achieved in this milestone as part of the grant. | +| 1. | Substrate module: swap | We will create a Substrate module that will make exchanges for different o-tokens. | +| 2. | Substrate chain | Modules omniverse assets, protocol & swap of our custom chain will interact in such a way that can make swaps between two different kind of o-tokens, user can add liquidity themselves, the O-AMM model can be calculated off-chain and verified on-chain. | +| 3. | Ink! smart contract implementation | We will create the fully O-DLT protocol in `Ink!` tech stack. It will have the same functions as in `Substrate Pallets` | +| 4. | Off-Chain Synchronizer | We will provide the source code and the executable program of the off-chain synchronizer. | + +## Future Plans + +- Firstly, we will make out a mechanism similar to abstract account smart contract to make omniverse tokens absolutely compatible to current native and ERC20/721 like tokens so that o-tokens on Polkadot/kusama can exchange with current tokens. +- Secondly, we will provide a mechanism to make omniverse tokens exchange with current native and ERC20/721 like tokens in other DEX like Uniswap. +- Thirdly, we will make the token of Dante omniverse so that it will be better to integrate with the inter-operability functions of the Dante Network. + +## Additional Information :heavy_plus_sign: + +Firstly, we really appriciate the help and support we have got from Web3 Foundation, with which we have completed the first steps of Dante Network. + +Secondly, we want to report some new progresses and plans of Dante Network. +- On one side, Dante's token will base on O-DLT, and we believe it will be a brand-new asset paradigm. +- On another side, we are trying to make more steps be deterministic when interactions happen between heterogeneous consensus spaces. We have found a multi-layer gaming model that may provide higher security and more efficiency. Maybe we will apply for another grant after we finish the detailed designation. + +Thirdly, as always, we highly endorse the philosophy of the Web3 Foundation. We are continuing to build more and deeper on Polkadot. + diff --git a/applications/OpenSquare-offchain-voting.md b/applications/OpenSquare-offchain-voting.md index 3204ce6c7f6..57aae3064ec 100644 --- a/applications/OpenSquare-offchain-voting.md +++ b/applications/OpenSquare-offchain-voting.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# OpenSquare off-chain voting for Polkadot ecosystem -* **Project Name:** OpenSquare off-chain voting for Polkadot ecosystem * **Team Name:** OpenSquare * **Payment Address:** 0x4905083abdD13bd95345A871701Fd0b08AbD46d1 (USDT) @@ -11,45 +10,48 @@ In short, you can see this proposed platform as [snapshot](https://snapshot.org) in the polkadot ecosystem. Though Polkadot/Kusama and most other Substrate based chains have on-chain governance and runtime can be easily upgraded with democracy. We think this platform still make sense with following reasons: -- Compared to the formal on-chain votes, this platform provides not so formal off-chain signed polls which may help token holders and community members engage **more** in the ecosystem building. -- Compared to Polkassembly polls on post: - - users have to sign their votes and the signed data will be stored on IPFS - - users don’t have to do any registration. - - Different strategies can also be provided to calculate the final result, rather than simply count the vote numbers. -- Not all on-chain systems with assets on Substrate based chains can upgrade with democracy, like assets issued on Statemine, ERC-20 assets which may be issued on Moonriver, Karura, Shiden, etc. +* Compared to the formal on-chain votes, this platform provides not so formal off-chain signed polls which may help token holders and community members engage **more** in the ecosystem building. +* Compared to Polkassembly polls on post: + * users have to sign their votes and the signed data will be stored on IPFS + * users don’t have to do any registration. + * Different strategies can also be provided to calculate the final result, rather than simply count the vote numbers. +* Not all on-chain systems with assets on Substrate based chains can upgrade with democracy, like assets issued on Statemine, ERC-20 assets which may be issued on Moonriver, Karura, Shiden, etc. ### Project Details + Off-chain votes will be an important part of OpenSquare collaboration platform. Other planned collaboration forms include bounties, payment QA, short term employment, etc. Key components in this proposal include: -- Predefined spaces where users can create proposals. It will definitely include Kusama and Polkadot, current para-chains with very high possibility. -- Proposal list in one space where users can view the closed or ongoing proposals. -- Proposal detail page where users can view the detail and the signed votes. -- A proposal discussion arena where users submit the signed messages and here we expect chaos. -- An authoring page where users can create proposals, and set the corresponding snapshot height, start and end date(height). -- Archive nodes interaction with which we read users’ balances on the corresponding snapshot block height. -- A backed server to interact with the node(Polkadot, Kusama, etc), store the organized data to DB, handle IPFS storage, provide APIs to get data. +* Predefined spaces where users can create proposals. It will definitely include Kusama and Polkadot, current para-chains with very high possibility. +* Proposal list in one space where users can view the closed or ongoing proposals. +* Proposal detail page where users can view the detail and the signed votes. +* A proposal discussion arena where users submit the signed messages and here we expect chaos. +* An authoring page where users can create proposals, and set the corresponding snapshot height, start and end date(height). +* Archive nodes interaction with which we read users’ balances on the corresponding snapshot block height. +* A backed server to interact with the node(Polkadot, Kusama, etc), store the organized data to DB, handle IPFS storage, provide APIs to get data. ![os_grant_voting](https://user-images.githubusercontent.com/2264908/127607269-5d54f0b0-d8b8-48f1-9c7a-fc8c205bc645.png) Some implementation notes: -- We have to call polkadot.js extension to sign the voting/poll, and some discussion messages. -- About voting power, since Polkadot/Kusama have proxy accounts, so we have to support proxy account vote on behalf of the original one. -- In this proposal, we will implement `balance of account` and `quadratic balance of account` strategies for Polkadot and Kusama. It means if Alice's balance is 100 at one chain height, her voting power will be 100 and 10 by these 2 strategies. -- We have a partnership with [Crust](https://crust.network/), and we may store data to IPFS through [decoo](https://decoo.io/) that crust granted. +* We have to call polkadot.js extension to sign the voting/poll, and some discussion messages. +* About voting power, since Polkadot/Kusama have proxy accounts, so we have to support proxy account vote on behalf of the original one. +* In this proposal, we will implement `balance of account` and `quadratic balance of account` strategies for Polkadot and Kusama. It means if Alice's balance is 100 at one chain height, her voting power will be 100 and 10 by these 2 strategies. +* We have a partnership with [Crust](https://crust.network/), and we may store data to IPFS through [decoo](https://decoo.io/) that crust granted. ### Ecosystem Fit + - Providing off-chain voting/polls to help token holders/community members engage more in ecosystem building. -- Flexible strategies help produce different voting/poll results which bring us different opinions from the on-chain tallying methods. -- [snapshot](https://snapshot.org) is popular for Ethereum stack projects, mainly for governance, and currently we didn't see similar projects in Polkadot ecosystem. +* Flexible strategies help produce different voting/poll results which bring us different opinions from the on-chain tallying methods. +* [snapshot](https://snapshot.org) is popular for Ethereum stack projects, mainly for governance, and currently we didn't see similar projects in Polkadot ecosystem. ## Team :busts_in_silhouette: ### Team members + - Yongfeng Li(@wliyongfeng), Full stack developer -- Chaojun Huang(@hyifeng), Full stack developer -- Wentao Chen(@qiyisi), Full stack developer -- Yizhou Xin(@YoshiyukiSakura), Full stack developer -- Alcazar(@Popoulosss), Designer -- Yaping Wu, BD and execution member +* Chaojun Huang(@hyifeng), Full stack developer +* Wentao Chen(@qiyisi), Full stack developer +* Yizhou Xin(@YoshiyukiSakura), Full stack developer +* Alcazar(@Popoulosss), Designer +* Yaping Wu, BD and execution member You can see our team with this [link](https://www.opensquare.network/team/). @@ -60,15 +62,16 @@ You can see our team with this [link](https://www.opensquare.network/team/). * **Website:** https://www.opensquare.network ### Legal Structure + * **Registered Address:** 3 FRASER STREET #05-25, DUO TOWER, SINGAPORE 189352 * **Registered Legal Entity:** OPENSQUARE FOUNDATION LTD. ### Team's experience We have more than 3 years experience with Substrate/Polkadot related tech stack. Our recently developing products include: -- [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve the treasury mechanism with retrospection. -- [Statescan](https://www.statescan.io), a fungible asset explorer for Statemint implementation chains. -- OpenSquare bounties business built on substrate. We got a grant for this, and please check details [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/open_square_network.md). +* [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve the treasury mechanism with retrospection. +* [Statescan](https://www.statescan.io), a fungible asset explorer for Statemint implementation chains. +* OpenSquare bounties business built on substrate. We got a grant for this, and please check details [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/open_square_network.md). We are honored that either dotreasury or statescan get support from kusama or polkadot treasury, and our work about bounties is granted by w3f previously. We are confident to deliver a high quality and usable off-chain voting site. @@ -77,11 +80,11 @@ https://github.com/opensquare-network/ Team members github accounts: -- https://github.com/wliyongfeng -- https://github.com/hyifeng -- https://github.com/qiyisi -- https://github.com/YoshiyukiSakura -- https://github.com/Popoulosss +* https://github.com/wliyongfeng +* https://github.com/hyifeng +* https://github.com/qiyisi +* https://github.com/YoshiyukiSakura +* https://github.com/Popoulosss ## Development Roadmap :nut_and_bolt: @@ -89,24 +92,24 @@ Only 1 milestone in this proposal, while the main goal is to check the feasibili We will put more features like more plugins and strategies in future proposals, but after this proposal we will launch it and make it available to the community. Milestone 1 — Implement Basic off-chain voting/polls logic for Polkadot & Kusama -- Estimated duration: 2 weeks -- FTE: 3 -- Costs: 8,000 USD +* Estimated duration: 2 weeks +* FTE: 3 +* Costs: 8,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Code | Code will be open source, organized in one monorepo by [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/), hosted on [OpenSquare github account](https://github.com/opensquare-network/). It will be implemented in JavaScript, [React](https://reactjs.org/) for fronted, [koa](https://koajs.com/) for backend. Either fronted and backed will depend on polkadot.js, while fronted will also depend on [extension-dapp](https://github.com/polkadot-js/extension/tree/master/packages/extension-dapp) to interact with polkadot{.js} extension. | +| 0b. | Code | Code will be open source, organized in one monorepo by [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/), hosted on [OpenSquare github account](https://github.com/opensquare-network/). It will be implemented in JavaScript, [React](https://reactjs.org/) for fronted, [koa](https://koajs.com/) for backend. Either fronted and backed will depend on polkadot.js, while fronted will also depend on [extension-dapp](https://github.com/polkadot-js/extension/tree/master/packages/extension-dapp) to interact with polkadot\{.js} extension. | | 0c. | Documentation | We will provide a documentation site to explain necessary concepts, how this site work, and some user workflows. | | 0d. | Test cases | Core functions will be covered by unit tests to ensure functionality and robustness. They will could be verified in simple npm scripts. | | 1. | User story 1 | Alice opens OpenSquare.io(domain not finally decided) and she can see spaces at least include polkadot and kusama. She can see a closed and ongoing proposal list after clicking a space. | | 2. | User story 2 | Alice will see the proposal description, votes records and the final result or analysis/distribution on a closed proposal page. | -| 3. | User story 3 | Alice votes yes on an ongoing proposal with polkadot{.js} extension, she can see her vote and re-vote to override the previous one. The reason that she changed her vote is that she checked the discussion and found some related news. | +| 3. | User story 3 | Alice votes yes on an ongoing proposal with polkadot\{.js} extension, she can see her vote and re-vote to override the previous one. The reason that she changed her vote is that she checked the discussion and found some related news. | | 4. | User story 4 | Alice created a proposal with the title “Should there be a specified UI for the society features?” and some description, and there are 2 choices: yes and no. She chose the voter balance as the final result strategy, while she can also choose sqrt balance as the strategy. With a very high sumed balance vote yes to Alice’s proposal, she now is very confident to seek more support to go on with following actions. | | 5. | User story 5 | Bob wanted to create a proposal at kusama height 1000, but failed, because his account has 0 balance. Anybody can create a proposal, but the minimum requirement is having at least 10 KSM at the target height. | ## Future Plans -- Add more spaces, and in the future users may create their own space and customize it. -- Support plugins and more strategies so users can customize the process and voting result. -- Support voting by assets issued on statemine or erc-20 tokens. +* Add more spaces, and in the future users may create their own space and customize it. +* Support plugins and more strategies so users can customize the process and voting result. +* Support voting by assets issued on statemine or erc-20 tokens. diff --git a/applications/OpenSquare_paid_qa_protocol.md b/applications/OpenSquare_paid_qa_protocol.md index bc1e02193c2..0c29c56df5f 100644 --- a/applications/OpenSquare_paid_qa_protocol.md +++ b/applications/OpenSquare_paid_qa_protocol.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# OpenSquare Paid QA protocol -* **Project Name:** OpenSquare Paid QA protocol * **Team Name:** OpenSquare * **Payment Address:** 0x4905083abdD13bd95345A871701Fd0b08AbD46d1 (USDT) @@ -41,42 +40,42 @@ DAPP implementers may do the submission in a batch way. The packages or components we have to implement includes: -- A scan package which tracks the interactions on a blockchain, and stores the structured data to the database. -- Scripts which interact with IPFS, fetch or upload content. -- A restful server will handle api calls from user interfaces and serve the structured data to them. -- A backend job which aggregates the signed answers and submits them to blockchain in a batch extrinsic. -- User interfaces. +* A scan package which tracks the interactions on a blockchain, and stores the structured data to the database. +* Scripts which interact with IPFS, fetch or upload content. +* A restful server will handle api calls from user interfaces and serve the structured data to them. +* A backend job which aggregates the signed answers and submits them to blockchain in a batch extrinsic. +* User interfaces. The user interfaces will include: -- A topic list page where users can see all the topics. Each topic is shown with its author, title, created time, +* A topic list page where users can see all the topics. Each topic is shown with its author, title, created time, status, etc. There may be some filters, like token currency filter and amount filter. -- A topic authoring page where a topic author can edit the topic, sign the extrinsic and submit to blockchain. -- A topic detail page: - - It shows the topic details and the answers. - - A user can answer the topic and sign with his/her polkadot key. - - A user can support this topic and sign the extrinsic to blockchain. - - Any user can fund an answer or the topic. - - It will show all the fund records, including from, to and the funded tokens. - - The author and supporter can resolve the topic on this page. -- A user page which is identified by address: - - A list of the created/supported topics. - - A list answers. - - Statistics of funds granted and received. - - Maybe some interfaces for operations, like links to create a topic. -- In site notifications(centralized) - - A topic author/supporter will receive a notification when there are new answers. - - An answer author will receive a notification when his/her answer gets funded. +* A topic authoring page where a topic author can edit the topic, sign the extrinsic and submit to blockchain. +* A topic detail page: + * It shows the topic details and the answers. + * A user can answer the topic and sign with his/her polkadot key. + * A user can support this topic and sign the extrinsic to blockchain. + * Any user can fund an answer or the topic. + * It will show all the fund records, including from, to and the funded tokens. + * The author and supporter can resolve the topic on this page. +* A user page which is identified by address: + * A list of the created/supported topics. + * A list answers. + * Statistics of funds granted and received. + * Maybe some interfaces for operations, like links to create a topic. +* In site notifications(centralized) + * A topic author/supporter will receive a notification when there are new answers. + * An answer author will receive a notification when his/her answer gets funded. Please check part of the UIs [here](https://www.figma.com/proto/vqpglMGW8psHKB00eIVDUV/OpenSquare?page-id=3655%3A16149&node-id=3659%3A30988&viewport=322%2C48%2C0.08&scaling=min-zoom). ### Ecosystem Fit -- It’s `system#remark` based, lightweight, and gas free for topic answers. -- Target audience are all the community members who have questions to ask or topics to discuss, and who have knowledge +* It’s `system#remark` based, lightweight, and gas free for topic answers. +* Target audience are all the community members who have questions to ask or topics to discuss, and who have knowledge to share. -- It provides a way with bounty for Pokadot ecosystem community members to share knowledge. -- I know [mem.co](https://mem.co/) who has similar planned products, but currently seems no products released. We +* It provides a way with bounty for Pokadot ecosystem community members to share knowledge. +* I know [mem.co](https://mem.co/) who has similar planned products, but currently seems no products released. We OpenSquare developed a centralized paid QA platform in Chinese, but we think decentralization should be the right direction. @@ -84,11 +83,11 @@ Please check part of the UIs [here](https://www.figma.com/proto/vqpglMGW8psHKB00 ### Team members -- Yongfeng Li(@wliyongfeng), Full stack developer -- Chaojun Huang(@hyifeng), Full stack developer -- Wentao Chen(@qiyisi), Full stack developer -- Yizhou Xin(@YoshiyukiSakura), Full stack developer -- Alcazar(@Popoulosss), Designer +* Yongfeng Li(@wliyongfeng), Full stack developer +* Chaojun Huang(@hyifeng), Full stack developer +* Wentao Chen(@qiyisi), Full stack developer +* Yizhou Xin(@YoshiyukiSakura), Full stack developer +* Alcazar(@Popoulosss), Designer You can see our team [here](https://www.opensquare.network/team/). @@ -108,13 +107,13 @@ You can see our team [here](https://www.opensquare.network/team/). We have more than 3 years experience with Substrate/Polkadot related tech stack. Our recently developing products include: -- [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve +* [doTreasury](https://www.dotreasury.com/). We can now see it as a treasury business explorer but it aims to improve the treasury mechanism with retrospection. -- [Statescan](https://www.statescan.io). An explorer for asset para chains, and we have implemented +* [Statescan](https://www.statescan.io). An explorer for asset para chains, and we have implemented Statemine/Statemint/Westmint. -- OpenSquare bounties business built on substrate. We got a grant for this, and please check +* OpenSquare bounties business built on substrate. We got a grant for this, and please check details [here](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/open_square_network.md). -- OpenSquare off chain [voting](https://voting.opensquare.io/) platform. We got a grant to develop it, please check +* OpenSquare off chain [voting](https://voting.opensquare.io/) platform. We got a grant to develop it, please check details [here](https://github.com/w3f/Grants-Program/blob/master/applications/OpenSquare-offchain-voting.md). We have supported Statemine assets since the grant delivery and got RMRK as our first user. @@ -124,30 +123,30 @@ https://github.com/opensquare-network/ Team members github accounts: -- https://github.com/wliyongfeng -- https://github.com/hyifeng -- https://github.com/qiyisi -- https://github.com/YoshiyukiSakura -- https://github.com/Popoulosss +* https://github.com/wliyongfeng +* https://github.com/hyifeng +* https://github.com/qiyisi +* https://github.com/YoshiyukiSakura +* https://github.com/Popoulosss ## Development Roadmap :nut_and_bolt: ### Overview -- **Total Estimated Duration:** 6 weeks -- **Full-Time Equivalent (FTE):** 5 FTE -- **Total Costs:** 25,000 USD +* **Total Estimated Duration:** 6 weeks +* **Full-Time Equivalent (FTE):** 5 FTE +* **Total Costs:** 25,000 USD Milestone 1 — Implement the paid QA businesses -- **Total Estimated Duration:** 6 weeks -- **Full-Time Equivalent (FTE):** 5 FTE -- **Total Costs:** 25,000 USD +* **Total Estimated Duration:** 6 weeks +* **Full-Time Equivalent (FTE):** 5 FTE +* **Total Costs:** 25,000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Code-1 | Code will be open source, most organized in one monorepo by [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/), hosted on [OpenSquare github account](https://github.com/opensquare-network/). It will be implemented in JavaScript, [React](https://reactjs.org/) for fronted, [koa](https://koajs.com/) for backend. Either fronted and backed will depend on polkadot.js, while fronted will also depend on [extension-dapp](https://github.com/polkadot-js/extension/tree/master/packages/extension-dapp) to interact with polkadot{.js} extension. | +| 0b. | Code-1 | Code will be open source, most organized in one monorepo by [yarn workspaces](https://classic.yarnpkg.com/en/docs/workspaces/), hosted on [OpenSquare github account](https://github.com/opensquare-network/). It will be implemented in JavaScript, [React](https://reactjs.org/) for fronted, [koa](https://koajs.com/) for backend. Either fronted and backed will depend on polkadot.js, while fronted will also depend on [extension-dapp](https://github.com/polkadot-js/extension/tree/master/packages/extension-dapp) to interact with polkadot\{.js} extension. | | 0c. | Code-2 | Scan scripts will be hosted under one of the packages which track blocks and extract the [qa-spec](https://github.com/opensquare-network/qa-spec) interactions into structured business data and save them to DB. | | 0d. | Code-3 | IPFS related functions which fetch content from IPFS and upload content to IPFS will be hosted under another package. These functions will be called when 1. Scan script finds spec interactions and we have to fetch the corresponding topic/answer from IPFS. 2. When a user creates a topic or gives an answer, IPFS functions will be called to upload the data to IPFS. 3. A background job which uploads content to IPFS in batch may also call these functions.| | 0e. | Code-4 | There will be another package which hosts background jobs. The jobs upload the topics/answers to IPFS in a batch and submit the `ANSWER` interactions in a batch to blockchain. | @@ -170,10 +169,10 @@ Milestone 1 — Implement the paid QA businesses ## Future Plans -- Support more chains and add more token identifiers, so users can collaborate with more tokens. -- Add more topic field definitions, so users can collaborate with more ways, for example, a field to support a poll +* Support more chains and add more token identifiers, so users can collaborate with more tokens. +* Add more topic field definitions, so users can collaborate with more ways, for example, a field to support a poll topic, a field to help users make categories. -- Credit/reputation building based on the behaviors, but it will be a long pan which need considerations together with +* Credit/reputation building based on the behaviors, but it will be a long pan which need considerations together with other collaborations in OpenSquare developed platforms. ## Additional Information :heavy_plus_sign: diff --git a/applications/P2PStateChannels.md b/applications/P2PStateChannels.md new file mode 100644 index 00000000000..7f68443f3fd --- /dev/null +++ b/applications/P2PStateChannels.md @@ -0,0 +1,281 @@ +# P2P State Channels + +> This document will be part of the terms and conditions of your agreement and, therefore, needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines (except for the title)! Lines starting with a `>` (such as this one) should be removed. Please use markdown instead of HTML (e.g., `![](image.png)` instead of ``). +> +> See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. + +- **Team Name:** SIGMA 8 SOLUTIONS +- **Payment Details:** + - **DOT**: 15ZzLCvcrZXDCddQnUGgzNUcMkSK4PugKdraQp8pFawoDWz1 + - **USDT (Asset Hub)**: 15ZzLCvcrZXDCddQnUGgzNUcMkSK4PugKdraQp8pFawoDWz1 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 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.* + +## Project Overview :page_facing_up: + +The tech part (minimal feature set - MFS) of our previous DF proposal - https://docs.google.com/document/d/1DcDFScgeXijnXSGuaa30uOnYNtRm_9OnAsM97igrSwA/ + +# Overview + +### Tagline: +Framework for creating client side peer-to-peer (p2p) state channels for arbitrary state machines with shared security inherited from a distributed ledger (blockchain). All the peer-to-peer networking is done between users’ clients. + +### Brief description: +The main goal of the project is to create fully peer-to-peer applications (without any central servers) that are highly scalable, resilient and secure, but also provide the building blocks by solving common problems to enable others to do the same. + +Peer-to-peer (p2p) state channels have many benefits—they’re highly scalable and decentralized due to their network topology and tendency to partition state within their group of interaction. They offer real-time communication that’s ‘free’ (no transaction fee) but do not act like a trusted party like blockchains do. + +What we aim to achieve is combine the best of both worlds, the decentralized and scalable nature of full p2p systems, while also inheriting full security from a distributed ledger. + +Notice that society works in the exact same way. For most of our lives, we (peers) interact with other peers in small groups (partitions). We (peers) form agreements and commit to faithfully executing on them and in the case where those agreements fail, we go to a court system to dispute one another inorder to enforce those agreements. The courts have limited capacity and their intervention is slow and expensive, but they are trusted by all parties (that freely chose to be in that jurisdiction) to be impartial, objective and faithfully come to a verdict on the agreement/law (state machine). + +### How does this relate to Polkadot +The value proposition for Polkadot is improving the user experience by providing a ‘free’ real-time execution environment which all parachains currently lack and expanding the market by onboarding new users and developers into the ecosystem. + +# Project Details + +This section will be used to expand on the technical solution and the architecture. + +The system is composed of a client side framework/SDK and on-chain smart contracts. + +Tech stack: +On-chain: smart contracts (solidity) +Off-chain (p2p) - written in typescript, holepunch for p2p and discovery, ethereumjs for running the EVM on client, ethers for manipulating and signing evm data and everything else is built from scratch (typescript). The entire design is state machine and runtime independent (can support substrate) - it works with native tooling. + +### The main responsibilities of the client side framework are: +1) Networking - establishing direct peer-to-peer connections and discovery over various transports (currently Holepunch), +2) State machine replication - allowing connected peers to commit to state machines and allowing them to progress and replicate those state machines, +3) Agreement tracking - tracking agreements on the order of transactions and state, managing forks, checking and collecting signatures, finalizing state +4) Virtual (logical) clock - Having a local logical clock that’s synced to the DLT clock (timestamp) - allows peers to have a local perception of time that mimics the one of the DLT, but tolerates skewness to a degree. This is of course subjective and peers will never reach consensus on the clock nor with other peers nor with the DLT itself. This is very important and will be discussed further below, +5) Dispute handling - constructing fraud proofs when a peer deviates from the protocol, +6) Observing and notifying on state change - hooks that allow external systems to subscribe and get notified when state changes happen - analogous to on-chain events. + +# + +1) P2PManager +Manages all peer-to-peer connections - how they’re established, which transport is used, receiving and broadcasting messages (RPCs) to other peers. +The message is interpreted on the RPC level and passed through appropriate pipelines based on the type of RPC. In the case of transactions, they’re forwarded to the StateManager for further processing. + + +2) StateManger +The central component of the system. It’s responsible for maintaining the correct state. It receives both p2p messages (transactions) and emitted events that happened on-chain. + +Received transactions pass through a verification pipeline (check signatures, is the signer part of the state channel, is it a duplicate, check timestamp, does it apply to the current state…). If all the checks pass, the transaction is applied to the state machine by invoking the stateTransition function. If everything is executed successfully, the signedTransaction is passed to the AgreementManager. If something fails, a dispute is invoked on-chain (if a cryptographic proof can be created to prove fraud) + +Received on-chain events - SetState is emitted when the DLT enforces a correct state of the state machine. This creates a fork (check Agreements and Forks) and sets the genesis state for the fork. This and everything else that’s enforced through the DLT is accepted as correct unconditionally, since the DLT is the single uncontested source of truth and every honest peer continues building on the latest fork. + +Timeout - + This is another responsibility of the StateManager. +There are 3 objective time parameters set for each state machine during creation: + +p2pTime - the max amount of time a peer can take to decide, execute and broadcast their Tx to other peers, +agreementTime - accounts for reasonable network delay, execution time and skewness of clocks. All agreements on the Tx (state transition) should happen within this time, +chainFallbackTime - if p2p agreements fail within p2pTime + agreementTime, this is the last resort allowing peers to post on chain. + + +When a peer fails to produce and broadcast a transaction that will progress the state machine forward within p2pTime + agreementTime in comparison to the previous transaction timestamp (each peer does this calculation in comparison to their local logical clock (this is subjective - see Clock)) - other peers won’t sign the transactionConfirmation even if they receive the transaction later. The peer still has time to invoke their transaction, but is forced to post the transaction on-chain as calldata (lazy execution) within chainFallbackTime. If the peer fails to do so and does not have all N signatures after that time expires (in comparison to the DLT clock), any peer (usually the one(s) that didn’t sign the confirmation) can invoke a dispute to remove the peer from the state channel (see Dispute Logic). The peer that was removed can challenge this dispute by providing all N signatures (confirmations) on the transaction and if successful the removal is reverted and the peer who initiated the dispute is removed and is fully slashed (penalty for byzantine behavior). + +An honest peer can produce and broadcast a Tx that progresses the state machine forward within p2pTime + agreementTime, but another (byzantine) peer can refuse to sign the message confirmation and in such the issuing peer will never have all N signatures and will again be forced to post on-chain inorder to guarantee it won’t be removed from the state channel. In that case the peer will refuse to sign confirmations of transactions from other peers that failed to sign its transaction, forcing them to also post calldata on-chain. Like this, both peers are at an economic disadvantage, since posting on-chain invokes transaction fees, so the optimal move is to cooperate to save on transaction fees, knowing that failure to cooperate results in economic costs. However, the DLT will guarantee correct progression of the state machine even if only 1 peer is honest and all N-1 are byzantine. (see Agreements) + +Clock +Every peer has a local subjective logical clock. The clock is synced with the DLT +clock (timestamp) in order to provide a local perception of time that mimics the DLT +time. Peers will never reach consensus on their clocks nor amongst themselves nor +with the DLT itself. The protocol is designed to tolerate skewness to a degree. Peers use their clock to decide subjectively, how they want to interact with the system and other peers - are incoming transactions too far in the future, too far in the past or about in time and based on their subjective opinion they come to an agreement or abstain from signing p2p. They use this clock also to invoke Timeout. While the perception of time is subjective and is designed to tolerate skewness to a degree, once measured and recorded as a timestamp, that information is objective and comparable. While each peer will compare it to their local clock and try to form agreements, if such agreements fail p2p and the system falls back on-chain, the DLT clock will prevail as a single uncontested source of truth and its comparison of the tx timestamp to its clock will be final. + +3) AgreementManager (Agreements) +The system does NOT implement a variation of a classical BFT (Byzantine Fault Tolerant) consensus algorithm due to lack of large economic security amongst peers in a partition and the strong design principle to allow everyone to connect freely with everyone. As such the system can’t guarantee that within a partition there will not be less than ⅓ byzantine actors as required by all classical BFT consensus algorithms. Since the DLT is used as a top level “supreme court”, we can design an optimistic consensus algorithm that tolerates N-1 byzantine actors - in other words we can design a system that’s Byzantine Fault Tolerant with at least 1 honest (non byzantine) actor by ultimately inheriting security from a DLT. + +Before explaining optimistic consensus, it’s important to understand the structure of a Transaction in this system: + +A transaction in this system references the exact state (previousStateHash) to which it is an input, and references the expected state post execution (stateHash). This resembles the logic behind UTXOs to a degree. + +Under optimistic consensus we can’t force peers to collaborate, but it’s in their best interest to do so, since failure to collaborate at best invokes posting calldata on-chain and paying transaction fees and at worst results in a full slash when provable fraud can be detected. Collaboration includes signing (confirming) all valid transactions without delay (satisfying agreementTime) and producing and broadcasting a transaction when it’s the peers turn to progress the state machine forward before timeout (check Timeout). + +Optimistic consensus is reached when all N signatures directly or indirectly (check Virtual Voting) reference the transaction (state). This finalizes the transaction (state). With at least 1 honest peer, an invalid state will never be finalized. + +If for any reason a peer doesn’t collect all N signatures on their issued transaction after agreement time, the peer will post their transaction on-chain (see Timeout). The peer will also opt out of signing transaction confirmations from peers that didn’t sign its transaction, forcing them too to post on-chain and too being at an economic disadvantage. Peers can at any time request to exit the state channel directly on the DLT if they don’t want to interact with other peers within the channel (subjective reputation and web of trust can help the peer initially decide with whom they want to connect, but is not required by the core protocol). + +Virtual Voting - Same concept as with blocks in a blockchain. Since blocks are cryptographically linked with past blocks through the parent hash, a block at block height K indirectly supports and thus votes for all previous K-1 blocks that precede it. In our case, a transaction issued is connected directly to the previous transaction through the previousStateHash and since this is recursive, it votes for all previous transactions that precede it. This is really practical, since a byzantine actor not wishing to sign confirmations of other peers will at some point have to produce a valid transaction or be removed through Timeout - producing a valid transaction indirectly confirms all previous transactions. This property is very useful especially with round robin leader election (block production / who writes next) and guarantees that at most the last N transactions are enough to finalize a state even if no one wants to directly cooperate peer-to-peer. + +Forks - +Forks ideally never happen and everyone cooperates fully p2p, without the need for the DLT ever to enforce a state, but in the case when the DLT has to step in, it creates a fork and sets the genesis state. The genesis state of a fork doesn’t require N signatures to be considered final since it’s enforced directly on the distributed ledger. Honest (non byzantine) peers always build on the latest fork. + +4) DisputeHandler - +Whenever a peer detects deviation from the protocl, they initiate a dispute by going through the DisputeHandler, which creates a dispute on-chain asking the DLT to enforce a correct state. To initiate a dispute a peer provides the last known finalized transaction (state) + all the transactions till the latest one the peer signed (confirmed) (this is at most N transactions in total - see Virtual Voting). After initiating a dispute, the peer stops signing transactions for the given fork. Due to the chain not having all the data and ideally not having any, the disputes are not final and have a challenge period where they can be contested. If successfully challenged (by providing more data), the disputter is fully slashed, a correct state is enforced and the challenge window prolonged. All honest peers check the disputed data and without delay challenge it if possible, otherwise they continue building on the fork and let the challenge period expire. More details on Dispute Logic down below when we cover on-chain logic. + +5) DLTEventListener - +Observes the DLT for relative events and passes them to the StateManager. +In V1 the blockchain interaction will be done through a provider, which the peers trust. In V2 we’ll explore options of making peers ultra light clients so they can access the DLT directly and increase resilience (the bootstrapping problem makes this slight optimization not worth considering in V1, since some node has to always be trusted to provide the data). + +6) AStateMachine - +Abstract state machine that defines the base class/contract of compatible state machines. While any state and state transition can be implemented and thus supporting arbitrary state machines, the system does require a minimal interface with some minimal properties. + +7) StateObserver - +Observes the concrete state machine and allows for other systems to subscribe for updates when the state changes. Analogous to on-chain events. + +The main responsibilities of on-chain smart contracts are: +1) Agreement verification - Verifies that all participants agree on a given state, +2) Dispute resolution (shared security) - Enforcing a correct state of the state machine if peer-to-peer agreements fail, +3) Settlement - final settlement of any assets that entered into the state channel, +4) Data Availability - Guaranteeing data availability for both state and transaction calldata if peer-to-peer agreements fail, +5) Liveness guarantees - In the case that the state machine can’t progress peer-to-peer, the DLT can progress it and remove any participants who failed to progress it within timeout, +6) Objective clock - provides a single global clock (timestamp) that’s uncontested and accepted as correct/true unconditionally. Peers sync their local logical clock to the DLT clock to mimic the DLT perception of time, + +Fraud proofs - fraud proofs in our system vastly differ from the ones of Optimistic Rollups such as Arbitrum/Optimism. The fraud proofs in their system are designed to work for servers that are handling transactions on behalf of other users and as such they have to post all the calldata on-chain for everyone to see and verify correctness or detect fraud. This is more expensive and less scalable, since more of the on-chain limited resources are being used. There are also no liveness guarantees, if the sequencer stops producing blocks. + +In our system, all the transactions being executed within the channel belong solely to the participants of the channel and as such they don't need to guarantee data availability for external parties. Data Availability comes into play only when peers fail to cooperate and as such its main goal is to guarantee data availability to other peers and provide a way to progress the state without cooperation or remove peers through Timeout. + +ADisputeManager (Dispute Logic): +ADisputeManager is an abstract contract that implements all the dispute logic and provides an interface that the StateChannelManager contract must implement. + +When a peer detects fraud locally, they initiate a dispute on-chain. In order to do so, they have to provide a proof of the last finalized state and all the transactions up to the last one the peer confirmed (this all can be done with at most the last N transactions and ideally with just 1 or 2). The peer also has to provide a fraud proof. + +StateChannelManager: +There can exist many state channels in parallel (open channels) and as such this contract manages all state channels - opening/closing the channel, keeping track of state (bytes) without interpreting it, allowing multiple state machines to be linked and invoking the correct one when needed, allowing peers to post their Tx as calldata and guaranteeing Data Availability to all. + +AStateMachine: +Abstract interface of a concrete state machine that only bears the state machine logic. Derived contracts execute p2p and when p2p agreements fail the same logic is used to enforce a correct state on-chan. + +### Ecosystem Fit + +Even though it will be built on top of the EVM, it's needed more in Polkadot than in Ethereum, since Ethereum rollups offer 'instant finality' to their users (they don't wait for L1 finality). It's compatible and built on top of native tooling. It's designed to be state machine and runtime agnostic, meaning that substrate can be supported in the future, when we have more resources to build the nesessary tooling to support it. For now the focus is on the user experience, that all parachains currently lack by having a real-time execution environmet without transaction fees. + +Where and how does your project fit into the ecosystem? +- On the core tech it fits as a public good / infrastructure by allowing everyone to build secure real-time p2p dApps. On the concrete state machines that we do/build, those are clearly dApps and provide a direct benefit to the end user. On the governance and upgrade side, Polkadot is the best fit by a long shot considering how it handles upgrades in contrast to others. + +Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's users, yourself)? +- The end user that uses the dApps is the target audience. That’s where the business model is. + +What need(s) does your project meet? +- Web2 user experience through real time communication that’s ‘free’, with web3 security guarantees. + +Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? +- Not that we’re aware of, not only in Polkadot / Kusama, but web3 in general since the state channels that are adopted are mostly payment channels and those are servers and in general all the scaling in web3 has been done on the ‘server’ side, while we focus fully on the client side. + +## Team :busts_in_silhouette: + +> Please note that the data provided in this section is for administrative and informational purposes only. All beneficiaries of a grant must also be listed in the KYC/KYB process during the application phase. See our [FAQ](https://grants.web3.foundation/docs/faq#what-is-kyckyb-and-why-do-i-have-to-provide-this-data) for more info. + +# Team members + +### Partially grant supported: + +Founder - Luka Stanisic +https://github.com/lukastanisic99 +https://www.linkedin.com/in/luka-stanisic-712907251/ + +Engineer - Dragan Basta +https://github.com/thepeaknick +https://www.linkedin.com/in/dragan-basta/ + +Designer - Aleksa Krstic +https://www.linkedin.com/in/aleksa-krstic-124880112/ + +Business development - Aleksa Gradinski +https://www.linkedin.com/in/aleksa-gradinski/ + +Business development - Gerard Murphy +https://www.linkedin.com/in/gerard-murphy-8939b520/ + +### Advisors / Not grant supported: + +Cryptography - Jeffrey Burdges +https://github.com/burdges +https://www.linkedin.com/in/jeffreyburdges/ + +Economics & legal - Kasper Mai Jørgensen +https://www.linkedin.com/in/kmjoergensen/ + +Engineering - Andrew Burger +https://github.com/coax1d +https://www.linkedin.com/in/andrew-b-8a628870 + + +# Contact + +- **Contact Name:** Luka Stanisic +- **Contact Email:** lukastanisic2@gmail.com + +### Legal Structure + +- **Registered Address:** Beogradska 55, 11194 Rusanj, Serbia +- **Registered Legal Entity:** SIGMA 8 SOLUTIONS (LLC) + +# Team's experience + +Luka - Background in engineering, protocol level of different DLTs (DAGs and blockchains), distributed systems at Microsoft Azure, Polkadot Blockchain Academy alumni with distinction. + +Dragan - Software engineer with 10+ years of experience. + +Aleksa Krstic - Senior UX/UI designer at another major DLT. + +Aleksa Gradinski - In crypto since 2017, CEO of Agroblock ($1M annual profit), helped in negotiations and expansion of leading web3 companies in Serbia. + +Gerard - Engineering degree holder with over a decade in high-end business development, overseeing multiple offices in the London property market. 15 years of professional poker playing and game theory expertise, bringing a strategic and analytical approach to business growth and a specific understanding of peer-to-peer commercial opportunities. + +Jeff - Applied cryptographer and mathematician at the Web3 Foundation. One of the lead protocol designers behind Polkadot and Kusama. + +Kasper - ex CFO Web3 Foundation and co-founder Polimec. + +Andrew - Researcher/Engineer at the Web3 Foundation + +## Development Status :open_book: + +In progress. + +## Development Roadmap :nut_and_bolt: + +Provide an SDK with a minimal set of features for alpha testing as soon as possible. + +# Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** Currently 1 person 24/7 and many part time with the team target going forward being 7 FTE +- **Total Costs:** $100000 - this covers the scope of this implementation +- **DOT %:** 50% (we're open to taking 100% in DOT, with 50% being vested over 2 years) + +# Milestone 1 and budget — Minimal feature set (MFS) - Blockchain components +- **Estimated duration:** 1.5 month +- **Costs:** 50000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | We'll provide examples and documentation on how to use the system. We'll also provide a video tutorial. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 1. | Channel Opening | All the logic required to open channels. Commitment to arbitrary state machine logic (bytecode) as defined in the document above. Performs all composable operations on the global state as required by the user specific state machine (depositing assets, interacting with other contracts). Atomic success or failure. | +| 2. | Cryptography | Cryptographic primitives to support threshold signature verification. Algorithm: ECDSA as used in Ethereum. Working with vanila EVM opcodes (no precompiles). Simple treshold algorithm. Base algorithm uses a highly audited library (openzeppelin). | +| 3. | Liveness | Liveness logic to progress the state channel even when peer-to-peer agreements fail. Part of the dispute resolution as defined in the document above. Posting calldata, invoking timeout logic and challenge when needed. Described in great detail above in timeout logic and optimistic consensus. | + +# Milestone 2 and budget — Minimal feature set (MFS) - Client side components (sdk/framework) +- **Estimated duration:** 1.5 month +- **Costs:** 50000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | We'll provide examples and documentation on how to use the system. We'll also provide a video tutorial. | +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article** that explains what was done as part of the grant | +| 1. | Networking and Discovery | Establishing p2p connections and discovery over holepunch. Using a permissionless DHT (distributed hash table) for peers to discover one another and using the holepunch algorithm to establish a direct peer-to-peer connection. | +| 2. | P2P State Machine | Running native smart contracts fully p2p. | +| 3. | Agreement Tracking | Tracking agreement on the state machine's state. Described in great detail above under agreement tracking | +| 4. | Dispute Handling | Invoking liveness logic when p2p state progression fails. Described in details above under disputes and timeout. | +| 5. | Virtual Clock | Using the DLT clock as the single source of truth in regards to time. Described in detail above under virtual clock. | +| 6. | Observing & Notifying | Hooks that allow external systems to subscribe and get notified when state changes happen. Described in detail above under observing and notifying on state change. | + +## Future Plans + +Everything we build, we build with resiliency, decentralization and scalability in mind. We never want to introduce a centralized server in our design or run any infrastructure. This offers a clear benefit to our users, but also to us, since we don’t have to maintain servers and our operational costs converge to 0 overtime. Our only long term costs should be development of new state machines and improving existing ones. We plan on picking and developing state machines that provide real utility, without any ponzi (unsustainable) economics. We want them to be useful and a better alternative to existing solutions today. We believe the systems we create can offer the good user experience of web2 (centralized) systems, with all of the web3 (decentralized) security and permissionless guarantees. + +While the core infrastructure will always remain free as a public good and accessible to everyone, the concrete state machines will have a business model that’s sustainable. + + + +## Additional Information :heavy_plus_sign: + +** Continuation of our DF proposal - Web3 Foundation diff --git a/applications/ParaSpell.md b/applications/ParaSpell.md new file mode 100644 index 00000000000..d7a0cfbe32b --- /dev/null +++ b/applications/ParaSpell.md @@ -0,0 +1,176 @@ +# ParaSpell + +- **Team Name:** ParaSpell +- **Payment Address:** 0xa085190c859eAe92bCCED9CE05b10DDb363FE5Ea (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 🐣 + +## Project Overview 📄 + +### Overview 💡 + +XCM & XCMP related development tool for developers. + +ParaSpell main advantages can be summarized in the following list: + +- ParaSpell is a platform that allows developers to use specific XCM & XCMP related tasks from a user-friendly interface. +- ParaSpell focuses on ease of use, broad scale of use cases, and bringing XCM & XCMP utilization & documentation closer to developers. +- ParaSpell guarantees to be a completely decentralized, open-source platform that does not collect any user data. + +One of the ParaSpell main goals is to reduce the time necessary to create XCM calls or open HRMP channels. + +Open channel + +As we can see in the figure above, the amount of details the user has to fill to transfer the XCM message is drastically reduced. As an example, users do not need to specify a specific route from origin to destination chain. These details are filled for them. + +Another goal of ParaSpell is having network installation, compilation & startup done as simply as possible. This is achieved by makefile that groups commands into fewer much more intuitive commands and by network startup configuration file. Together, these two files take care of the network side, and adding new nodes into these files is intuitive. Starting the application is also very simple and done by one command. Communication between application and network is made possible with Polkadot API libraries. + +ParaSpell focuses mainly on substrate developers. Added value comes from being user friendly SDK for simplifying development by saving time necessary to install & launch network, open HRMP channels or create XCM transfers between nodes available in network. + +Overall ParaSpell is all about developer experience. + +### Project Details 🎯 + +ParaSpell in its current form allows developers to install all dependencies as well as a network consisting of Rococo, Pichiu(Kylin network), Bifrost & Acala nodes with one command. Launching a network is also done by one command. Once the network is installed and started ParaSpell application allows developers to open/close HRMP channels between mentioned parachains. In current progress ParaSpell already has user interface and main functionality almost finished. + +The following screen allows the user to open the HRMP channels between list of parachains pulled from Rococo by API call. + +Open channel + +Closing HRMP channels is just as simple as opening them. One button click to close the required channel. + +close channel + +If the user decides to transfer funds from Relay chain to Parachain they can do so by filling following details. These required details are way faster to fill than filling a full XCM call which requires a complete route and selection of concrete token. + +relay to para + +The opposite, but nearly the same scenario is sending tokens from Parachain to Relay chain. It is just as simple, however. + +para to relay + +The last transaction scenario is the transfer of funds between Parachain and another Parachain. + +para to para + +- Overview video of application is also available on Youtube +[Link to overview video](https://youtu.be/YKZEa2MaY6Q) + +#### Architecture 🏗 + +![screenFlow](https://github.com/user-attachments/assets/618d97aa-437f-4c64-b3ab-a24ab21e75ea) + +Application is purposely designed to be as simple as possible. This guarantees, that all tasks can be done quickly and without extended searching. All necessary screens also feature notifications which will as a milestone explain be callback reactive. The loading screen is only present on the first application & network startup, once accessing the same screen after the application was loaded it will be skipped automatically. The screen serves to register necessary assets in parachain nodes. This is only required to be run once per network startup. + +#### Technology Stack 💻 + +- Vue.js +- Node.js +- Typescript +- Polkadot api libraries +- Make +- Polkadot launch +- Substrate compatible nodes (For now Rococo, Pichiu(Kylin network), Bifrost & Acala) + +### Ecosystem Fit 🌿 + +There are not many XCM & XCMP related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster. + +In Polkadot and Kusama ecosystem, there are few XCM & XCMP related Dapps in development. These rather focus on standard users mostly. One of mentioned type is called "Morph". + +Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains. + +Our target audiences can be Web3 projects & starting/current blockchain developers. + +## Team 👥 + +### Team members (In order of joining time) + +Dušan Morháč - Student, project Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava + +Viktor Valaštín - Supervisor, founder of [KodaDot](https://kodadot.xyz/). Faculty of Informatics and Information Technologies STU in Bratislava + +### Contact 📞 + +- **Contact Name:** Dušan Morháč +- **Contact Email:** [xmorhac@stuba.sk](mailto:xmorhac@stuba.sk) + +### Legal Structure + +- **Registered Address:** No legal structure yet. +- **Registered Legal Entity:** No legal structure yet. + +### Team's experience 🔎 + +- Dušan is the programmer behind this project and has successfully presented it at the international conference ICECET2022 held in Prague from which there is an article regarding XCMP & our project. It will soon be published on IEEE and a link will be provided. Dušan also studies blockchain technology and had a bachelor thesis about cross-blockchain sharing from which this idea was born. +- Viktor ([@vikiival](https://twitter.com/vikiival)) is building open-source software in the Polkadot ecosystem since 2019. Viktor is also Dušan's supervisor, Co-Founder of [KodaDot](https://kodadot.xyz/), and co-author of our XCMP ICECET2022 article publication. + +### Team Code Repos 📚 + +- [https://github.com/dudo50/ParaSpell](https://github.com/dudo50/ParaSpell) +- [https://github.com/kodadot/nft-gallery](https://github.com/kodadot/nft-gallery) + +#### Team github accounts 🧑‍💻 + +- [https://github.com/dudo50](https://github.com/dudo50) Dušan Morháč +- [https://github.com/vikiival](https://github.com/vikiival) Viktor Valaštín + +### Team LinkedIn Profiles 🧑‍🎓 + +- [https://www.linkedin.com/in/dudo50](https://www.linkedin.com/in/dudo50) +- [https://www.linkedin.com/in/vikival](https://www.linkedin.com/in/vikival) + +## Development Status 📖 + +- [https://github.com/dudo50/ParaSpell](https://github.com/dudo50/ParaSpell) This is the repo for ParaSpell and there is already a user interface that can open HRMP channels & transfer fungible tokens between Acala and Rococo. Wallet support from milestone was recently implemented, it only needs to be added to calls. + +## Development Roadmap 🔩🛠 + +### Overview + +- **Total Estimated Duration:** 2 months ⌛️ +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 10,000 USD 💰 + +### Milestone 1 — Cross-blockchain application for developers + +- **Estimated duration:** 2 months ⌛️ +- **FTE:** 1 FTE +- **Costs:** 10,000 USD 💰 + +| Number | Deliverable | Specification | +|--------|---------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0a. | License | MIT | +| 0b. | Documentation | Inline documentation of code, as well as startup configuration with all necessary commands, included in repository | +| 0c. | Testing Guide | Core functionality & user guide will be covered in repository documentation | +| 0d. | Docker | Frontend Docker file will be ready | +| 0e. | Article | Soon to be released on IEEE + Medium article about development of ParaSpell | +| 1. | Wallet login | Developers can use their Polkadot js extension wallets to execute transactions XCM from their accounts. | +| 2.a | Full working fund transfer scenario 1 | Fully working transaction scenario 1 - Relay chain to Parachains | +| 2.b | Fully working fund transfer scenario 2 | Fully working transaction scenario 2 - Parachains to Relay chain | +| 2.c | Fully working fund transfer scenario 3 | Fully working transaction scenario 3 - Parachain to Parachain | | +| 3.a | Callback support 1 | Added callback data support so developers/users can see information about their XCM transactions from UI and in real-time. | +| 3.b | Callback support 2 | Added callback data support so developers/users can see information about HRMP channel calls from UI and in real-time. | +| 4. | ParaSpell SDK | Move calls to separate NPM library | +| 5. | Guide to add new nodes to application and network | Simplified and user-friendly wiki/guide for users to understand how to add new nodes to network startup configuration as well as to add/understand calls used in application | + + +## Future Plans 🔭 + +Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels. + +In a long run, we also want to improve design, add new features that can be useful for developers, support for new nodes, and ability to add a new node from the user interface. + +## Additional Information ➕ + +**How did you hear about the Grants Program?** Personal recommendation + +**About project success so far:** + +- Project article was accepted on international conference ICECET2022 ( only 450 out of 1000+ articles got accepted) +[Link to conference physical program - Article 862](http://www.icecet.com/program_P.pdf) + + +- Project won 🥈 second place bounty at Polkadot North America Hackaton in category "Build an XCM Related Tool for Moonbeam" +[Link to moonbeam winner announcement twitter post]( +https://twitter.com/MoonbeamNetwork/status/1555654398658977792) +[Link to hackaton entry post](https://devpost.com/software/polkachange-cross-blockchain-transfer-tool) diff --git a/applications/ParaSpell_follow-up.md b/applications/ParaSpell_follow-up.md new file mode 100644 index 00000000000..3a86689358e --- /dev/null +++ b/applications/ParaSpell_follow-up.md @@ -0,0 +1,234 @@ +# ParaSpell + +- **Team Name:** ParaSpell✨ +- **Payment Address:** 0xB7d45Ef044fD9342e4c03e28D9e9bddA2d4Fe3e1 (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 🐤 + + +## Project Overview :page_facing_up: +Previously delivered: +[Proposal 1 for base funding ParaSpell](https://github.com/w3f/Grants-Program/blob/3905f49d0efcd3700670fc3e13c2d92a2f84a7fa/applications/ParaSpell.md) +### Overview +XCM & XCMP related development tool with SDK and UI created for developers. + +ParaSpell main advantages can be summarized in the following list: + +- ParaSpell is a platform that allows developers to use specific XCM & XCMP related tasks from a user-friendly interface. +- ParaSpell focuses on ease of use, broad scale of use cases, and bringing XCM & XCMP utilization & documentation closer to developers. +- ParaSpell guarantees to be a completely decentralized, open-source platform that does not collect any user data. +- ParaSpell allows other substrate projects to easily implement XCM & XCMP functionality with ParaSpell SDK + +One of the ParaSpell main goals is to reduce the time necessary to create XCM calls or open HRMP channels. +Another goal is to make XCM calls as easy as possible to construct via SDK while retaining full customizability of what is transferred through XCM message and where. + +![comparison](https://user-images.githubusercontent.com/55763425/198574902-1a9e1c98-9351-4f5d-894f-7e0158eabeaa.jpg) + +As we can see in the figure above, the amount of details the user has to fill to transfer the XCM message is drastically reduced. As an example, users do not need to specify a specific route from origin to destination chain. These details are filled for them. + +Another goal of ParaSpell is having network installation, compilation & startup done as simply as possible. This is achieved by makefile that groups commands into fewer much more intuitive commands and by network startup configuration file. Together, these two files take care of the network side, and adding new nodes into these files is intuitive. Starting the application is also very simple and done by one command. Communication between application and network is made possible with Polkadot API libraries. This can help future Parachain developers with testing. + +ParaSpell focuses mainly on substrate developers. Added value comes from being user friendly SDK for simplifying development by saving time necessary to install & launch network, open HRMP channels or create XCM transfers between nodes available in network. +Another added value comes from SDK that aims to connect entire Substrate ecosystem and in future also EVM with Substrate. + +Overall ParaSpell is all about developer experience. + +### Project Details +ParaSpell in its current form allows developers to install all dependencies as well as a network consisting of Rococo, Pichiu(Kylin network), Bifrost & Acala nodes with one command. Launching a network is also done by one command. Once the network is installed and started ParaSpell application allows developers to open/close HRMP channels between mentioned parachains. In current progress ParaSpell already has user interface and main functionality almost finished. + +The following screen allows the user to open the HRMP channels between list of parachains pulled from Rococo by API call. +![open channel](https://user-images.githubusercontent.com/55763425/198574223-8444aff5-a3f8-4d15-bf25-0ccf345e2577.png) + + +Closing HRMP channels is just as simple as opening them. One button click to close the required channel. +![close channel](https://user-images.githubusercontent.com/55763425/198574247-12a00f37-33a4-467a-aaaa-e83d913af558.png) + + +If the user decides to transfer funds from Relay chain to Parachain they can do so by filling following details. These required details are way faster to fill than filling a full XCM call which requires a complete route and selection of concrete token. +![relay to para](https://user-images.githubusercontent.com/55763425/198574295-30a4d124-8f72-4931-a3ee-2f3e1375d73b.png) + + +The opposite, but nearly the same scenario is sending tokens from Parachain to Relay chain. It is just as simple, however. +![para to relay](https://user-images.githubusercontent.com/55763425/198574386-d3883bfe-54ba-4e74-abcc-f08995a39703.png) + + +The last transaction scenario is the transfer of funds between Parachain and another Parachain. +![para to para](https://user-images.githubusercontent.com/55763425/198574413-8ef3714c-f971-4652-ab7f-b8114f8928bb.png) + + +- Overview video of application is also available on Youtube [Link to overview video](https://youtu.be/YKZEa2MaY6Q) + +#### Architecture 🏗️ +![screenFlow](https://user-images.githubusercontent.com/55763425/198412240-e031d877-c5d8-4952-9048-2e1256ba4469.svg) + +UI is purposely designed to be as simple as possible. This guarantees, that all tasks can be done quickly and without extended searching. All necessary screens also feature notifications which will as a milestone explain be callback reactive. The loading screen is only present on the first application & network startup, once accessing the same screen after the application was loaded it will be skipped automatically. The screen serves to register necessary assets in parachain nodes. This is only required to be run once per network startup. + +SDK currently handles transfers to 29 compatible Parachains (ones that have xTokens pallet) ([Beta-pre-release ParaSpell SDK](https://github.com/paraspell/sdk/tree/beta-pre-release)) and also can transfer to both Relay chains. It is easy to construct calls as is but we want to make it even easier and more developer friendly. + +#### Technology Stack 💻️ +- Vue.js +- Node.js +- Typescript +- Polkadot api libraries +- Make +- Parachain launch +- Substrate compatible nodes (For now Rococo, Pichiu(Kylin network), Bifrost & Acala) + +### Ecosystem Fit 🌳 + +There are not many XCM & XCMP related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster. + +In Polkadot and Kusama ecosystem, there are few XCM related tools in development. For example Moonbeam XCM SDK was released only recently. We bring comparison table that compares our ParaSpell SDK to Moonbeam SDK +| Features | ParaSpell XCM SDK | Moonbeam XCM SDK | +| -----: | ----------- | ------------- | +| Number of packages user has to install | User needs to install only 1 package | User needs to install 2 packages | +| Support for Parachains | Already integrated for every with xTokens & will be integrated for all with polkadotXCM pallet (Will be basically implemented for all nodes then) Link to implementation [Beta-pre-release ParaSpell SDK](https://github.com/paraspell/sdk/tree/beta-pre-release) | Every new node has to be added manually | +| Build pattern | Will be integrated, to be as intuitive as possible | Integrated, not as intuitive to implement however | +| Support for asset pallet operations | Will be integrated | Not integrated | +| Support for HRMP pallet operations | Integrated users can open & close HRMP channels on their local chain (Useful feature for devs) | Not integrated | +| Support for checking details that do not change | Will be integrated & will also be covered with some error handling eg (too little ammount being sent, not sufficient for XCM transfer) | Integrated in form of small "map" for different Tokens & Node IDs | +| Support for Axelar GMP (General message passing) that will connect Substrate with EVM chains | Planned to be implemented in the future | No data | + + + +Unlike the already mentioned "Moonbeam XCM" platform ParaSpell provides UI enhancement that uses our XCM SDK and users can try/learn technology from it. ParaSpell also includes support for all 29 Substrate Parachains ([Beta-pre-release ParaSpell SDK](https://github.com/paraspell/sdk/tree/beta-pre-release)) that have xTokens pallet compared to Moonbeam XCM to which users have to implement compatible nodes manually. ParaSpell SDK only needs one package compared to Moonbeam XCM which has total of two. Compared to Moonbeam XCM which contains only XCM calls ParaSpell also contains calls that can open or close HRMP channels. We also want to include support for Parachains that have template pallet for XCM called polkadotXCM this pallet is a little harder to work with than xTokens, even more for inexperienced developers. + +Another comparison worth mentioning is UI vs Morph which is also enhancement of XCM UI Transfer tool +| Features | ParaSpell XCM UI | Morph | +| -----: | ----------- | ------------- | +| Focus: | Developers & users that wish to try XCM locally first | Users | +| Wiki: | Comprehensive Wiki explaining XCM, how to add assets to UI & Nodes and more implemented | Not implemented | +| Support for transfers: | In three different scenarios | In two scenarios | +| Support for local network configuration: | Fully implemented example network configuration that uses maintained Parachain-launch library | Not implemented | +| Support for HRMP channel opening/closing: | Fully implemented | Not implemented | + +Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains. + +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 entire ecosystem in our opinion. + +Our target audiences are Web3 projects and starting/current blockchain developers. +## Team :busts_in_silhouette: + +### Team members + +Dušan Morháč - Student, project Core Dev. Faculty of Informatics and Information Technologies STU in Bratislava + +Viktor Valaštín - Supervisor, founder of [KodaDot](https://kodadot.xyz/). Faculty of Informatics and Information Technologies STU in Bratislava + +### Contact + +- **Contact Name:** Dušan Morháč +- **Contact Email:** xmorhac@stuba.sk + + +### Legal Structure + +- **Registered Address:** Tomášovská 453/2, Kalinovo 98501, Slovak Republic +- **Registered Legal Entity:** Dušan Morháč ml. + +### Team's experience + +- Dušan is the programmer & researcher behind this project and has successfully presented it at the international conference ICECET2022 held in Prague from which there is an article regarding XCMP & our project. It is published on [IEEE](https://ieeexplore.ieee.org/document/9872938). Dušan also studies Blockchain technology and had a bachelor thesis about cross-blockchain sharing from which this idea was born. Dušan is actively working on [ParaSpell](https://github.com/paraspell) full-time & have also created project called [MoonDo](https://github.com/dudo50/MoonDo) which he works on & researches during free time, research from it will be used in ParaSpell. MoonDo won second place bounty for Axelar in Moonbeam connected contracts hackathon [link](https://devpost.com/software/moondo). +- Viktor ([@vikiival](https://twitter.com/vikiival)) is building open-source software in the Polkadot ecosystem since 2019. Viktor is also Dušan's supervisor, Co-Founder of [KodaDot](https://kodadot.xyz/), and co-author of our XCMP ICECET2022 article publication. + +### Team Code Repos + +- https://github.com/paraspell +- https://github.com/dudo50/MoonDo +- https://github.com/kodadot/nft-gallery + +### Team Github Profiles 🧑‍🎓 + +- https://github.com/dudo50 Dušan Morháč +- https://github.com/vikiival Viktor Valaštín + +### Team LinkedIn Profiles 🧑‍🎓 + +- https://www.linkedin.com/in/dudo50 +- https://www.linkedin.com/in/vikival + +## Development Status :open_book: + +[UI](https://github.com/paraspell/ui) that uses XCM SDK has it's functionality implemented already which was main goal of our first proposal. We will shift it towards new version of Vue which is state of the art during fufillment of this proposal. SDK has [beta pre-release](https://github.com/paraspell/sdk/tree/beta-pre-release) phase released, it features all 29 nodes that implement xTokens pallet, ability to transfer to & from Relay chains, ability to open & close HRMP channels. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 6 months +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 28 500 USD + +### Milestone 1 - Improve ParaSpell UI 1/2 & ParaSpell SDK 1/3 + +- **Estimated duration:** 2 months ⌛️ +- **FTE:** 2 +- **Costs:** 9 500 USD 💰️ + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a usage explanation in readme.md | +| 0c. | Testing and Testing Guide | SDK Core UNIT tests will be provided for xTokens Pallet, HRMP pallet, polkadotXCM pallet| +| 0d. | Docker | Docker file that allows to test ParaSpell SDK through ParaSpell UI will be provided. | +| 1. | Create scaffold template for Web3 projects | Create template on Git for Web3 dApps to allow users to start developing and deploying in just minutes, this template will contain different libraries important for Web3 development already preinstalled. Languages planned to be used are `Typescript`. Stack that will be used is `Vue3 (Nuxt 3)`, `pnpm package manager`, `Polkadot API libraries` (Use KodaDot packages if applicable), `ParaSpell SDK`, UI will consist of basic components (address input (checks if address entered is valid), ballance input (no longer necessity to input lenghty amounts, will have sum conversions) etc.. ), wallet management (PolkadotJS, Talisman, Subwallet), all other not mentioned libraries will be mentioned in readme of template and readme will be linked to delivery. | +| 2. | Implement support for checking asset compatibility through `asset pallet` | Each node, that has ability to check which tokens it supports should be automatically queried for this data and SDK should be able to determine compatibility based on data queried. | +| 3.a | Add support for nodes without xTokens pallet I | We will implement support for transfer scenario Parachain to Relay chain for nodes that do not have xTokens pallet but have `polkadotXCM` prebuilt template pallet. (SDK will be able to determine which pallet to use on which Parachain automatically) | +| 3.b | Add support for nodes without xTokens pallet II | We will implement support for transfer scenario Parachain to Parachain for nodes that do not have xTokens pallet but have `polkadotXCM` prebuilt template pallet. (SDK will be able to determine which pallet to use on which Parachain automatically) | +| 4. | Make SDK easier to use | Merge Parachain to Parachain & Parachain to Relay chain scenarios in SDK into one scenario that will be able to adapt based on details provided (if destination node id not provided, then assume transfer is for relay chain, also if token is compatible with relay chain), this will replace need for calling two functions for each scenario with only one function covering both scenarios eg. `send()` instead `paratopara()` & `paratorelay()`| + +### Milestone 2 - Improve ParaSpell SDK 2/3 + +- **Estimated duration:** 2 months ⌛️ +- **FTE:** 2 +- **Costs:** 9 500 USD 💰️ + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a usage explanation in readme.md | +| 0c. | Testing and Testing Guide | SDK Core UNIT tests will be provided for pallets mentioned previously, script that checks pallets, functionality to check data that does not change, builder pattern | +| 0d. | Docker | Docker file that allows to test ParaSpell SDK through ParaSpell UI will be provided. | +| 1. | Add support for checking data that does not change | There are things that do not change, such as base token configuration (Polkadot, DOT token, 10 decimals), (Astar, ASTR, 18 decimals) This can be imported from `@polkadot/network` library to have better support for different transfer scenarios| +| 2. | Rewrite SDK to builder pattern | Best thing we can do to support multiple pallets and make it simplier for developers would be a Builder pattern functionality would look like: `import { Builder } as ‘@paraspell/sdk’` and then building of call would be something in sence: `const call = Builder(api).from(‘bsx’).to(‘ksm’).teleportTokens(‘KSM’).addr('destinationAddr').sum(currencySum).asV3().build()`| +| 3. | Make a map of compatible \ | Before each SDK release there should be a script that connects to the compatible nodes, checks all relevant available pallets `xTokens`, `polkadotXCM`, `asset pallets`, `HRMP` pallets) and saves them to the map.| +| 4. | Use [turborepo](https://turborepo.org/) | Remake package into `monorepo` for easier importing and cleaner use | + +### Milestone 3 - Improve ParaSpell UI 2/2 & ParaSpell SDK 3/3 + +- **Estimated duration:** 2 months ⌛️ +- **FTE:** 2 +- **Costs:** 9 500 USD 💰️ + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a usage explanation in readme.md | +| 0c. | Testing and Testing Guide | SDK Core UNIT tests will be provided for every scenario that SDK offers. | +| 0d. | Docker | Docker file that allows to test ParaSpell SDK through ParaSpell UI will be provided. | +| 0e. | Article | We will publish Medium article about development of SDK | +| 1. | Release new functionality | Ability to install new version of package from npm | +| 2.a | Update ParaSpell UI I | Update ParaSpell XCM UI Parachain to Parachain Scenario screen to be able to use new SDK (Add or remove some variables according to new requirements from SDK functions) | +| 2.b | Update ParaSpell UI II | Update ParaSpell XCM UI Relay chain to Parachain Scenario screen to be able to use new SDK (Add or remove some variables according to new requirements from SDK functions) | +| 2.c | Update ParaSpell UI III | Update ParaSpell XCM UI Parachain to Relay chain Scenario screen to be able to use new SDK (Add or remove some variables according to new requirements from SDK functions) | +| 3. | Add comprehensive Wiki guide | We will add Wiki guide, that will specify SDK implementation to another dApps, different SDK functionalities & Guide for Parachain creators that wish to add their freshly baked node to the list of compatible nodes. | +| 4. | Use scaffold template from Milestone 1 to update UI | This will update ParaSpell UI from Vue 2 into Vue3 and nuxt. It will also be good demonstration for template usage & it will make UI more compatible with other dApps. | +| 5. | Integrate suggestions from [evaluation](https://github.com/w3f/Grant-Milestone-Delivery/blob/1343c66d74a1078b2a30972463a614737ed8aa92/evaluations/paraspell_1_keeganquigley.md) | Integrate suggestions regarding Wiki, module for asset conversions to not need to write so many 0s & replace button text `Log in with:` with account name once logged in | + +## Future Plans 🔭 + +Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels. + +In a long run, we also want to improve design of the UI, add new features that can be useful for developers and support for new nodes. + +Project goal is that SDK will serve dApp developers and UI will teach new substrate developers to use XCM and will serve to existing substrate developers to test their freshly baked Parachains. +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Personal recommendation + +##### Project achievements in chronological order ⌛️ + +- 📙 Article about project created & presented on 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 a 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 funded [link](https://github.com/dudo50/Grants-Program/blob/d182e10ecbd7705aee07edc5f7aa0085d07188e5/applications/ParaSpell.md), [link2](https://medium.com/web3foundation/web3-foundation-grants-wave-15-recipients-5ac4e6406485). +- 🥈 Second place bounty in Moonbeam connected contracts Hackathon - Build Cross-chain application with Axelar [Link to hackathon post](https://devpost.com/software/moondo) diff --git a/applications/ParaSpell_follow-up2.md b/applications/ParaSpell_follow-up2.md new file mode 100644 index 00000000000..9057ea6acae --- /dev/null +++ b/applications/ParaSpell_follow-up2.md @@ -0,0 +1,246 @@ +# ParaSpell + +- **Team Name:** ParaSpell✨ +- **Payment Address:** 0xB7d45Ef044fD9342e4c03e28D9e9bddA2d4Fe3e1 (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 🐣 + + +## 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) + +What is ParaSpell: +ParaSpell is XCM & XCMP Developer tool ment to ease 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 call. As an example we provide image below. + + +![img1](https://user-images.githubusercontent.com/55763425/218987451-2bfc9526-8f2b-4477-8c42-8c70cbcb6ec4.jpg) + +In this image we can see, that ParaSpell saves much time to developers. Just one call can contain multiple lines of JSON which would otherwise have to be integrated manually by developer. ParaSpell does it in marginally less lines and hides complex logic of building message which ensures, that messages are constructed correctly. This call in the end results into following lengthy extrinsic: + +![img2](https://user-images.githubusercontent.com/55763425/218987583-f5fb10b2-2e0c-4f36-b01c-0d610deab1c6.jpg) + +Following extrinsic can be subscribed into and we can check for it's events on front end. ParaSpell provides front end for testing XCM transactions and XCM called [UI-V2](https://github.com/paraspell/ui-v2). This UI is also deployed on netlify so users only have to run local network to start testing. UI also provides ability to open or close HRMP channels or test out XYK pool functionality that was implemented in collaboration with HydraDX team. In the picture below we provide overview of the UI. +![img3](https://user-images.githubusercontent.com/55763425/218989950-acb681e3-b511-452b-bc3a-c9e5049f7dce.png") + + +### Overview 🎨 + +ParaSpell is split into three main repositories at the moment: + +- [XCM SDK](https://github.com/paraspell/xcm-sdk): Meant to unify cross-chain experience on Substrate. Can serve any dApp developer that wishes to integrate XCM or other pallets support for they app. +- [UI-V2](https://github.com/paraspell/ui-v2): Allows for launching local network and testing XCM or HRMP channels across that local network +- [Docs](https://github.com/paraspell/docs): Extensive documentary for overview of ParaSpell, guide for SDK and UI + + +#### SDK +This SDK currently support 42 compatible XCM nodes. They can transfer XCM messages in three different scenarios. +- Parachain to Parachain - HRMP +- Parachain to Relay chain - UMP +- Relay chain to Parachain - DMP + +SDK contains many useful features that allow for easier inntegration: +- Builder pattern implementation, easy to construct XCM calls, much more used recently for simplicity of implementation. + +- Suggestions, SDK contains TYPES that help to guide developer through integration. For example he get's compatible nodes suggested. +![1_59xApnboumYhzuRHKx60TA](https://user-images.githubusercontent.com/55763425/219314223-79c31085-2e90-4dc7-ad51-da96de730ea0.png) + +- Console printouts, SDK allows for printing into console so developer can alway check if 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.. + +#### UI-V2 +UI is used as testing tool for Parachain developers, they can simply add their node into network and test it with HRMP channels as well as XCM transfers. UI also allows dApp developers to test and learn XCM before integrating it from our SDK. + +UI is made to be as simple to use as possible. It is now also deployed on netlify so developers only have to start local network from configuration file provided by ParaSpell which starts network of Relay chain and 3 different Parachains (Bifrost,Karura & Pichiu) + +Below are some examples of UI with running network: +![img4](https://user-images.githubusercontent.com/55763425/219366458-8873418e-9487-4762-8327-56c3294accdd.png) + +Above we can see open/ close channel screen. It is simple to work with and intuitive. Nodes are pulled from relay chain by query so if network is not running you cannot see any nodes. + +![img5](https://user-images.githubusercontent.com/55763425/219366638-38ebcdd7-5ff6-4507-8209-fc7f3ccac348.png) + +Above we can observe, that UI contains simple Wallet login with test accounts. + +![img6](https://user-images.githubusercontent.com/55763425/219366771-be566565-8bf1-477b-b7c8-3eacec6f63a0.png) + +Above we can see XCM screen which is also very simple to navigate and nodes are pulled from relay chain by query. + +#### Docs +Docs contain important information regarding SDK, UI and other repositories that are in ParaSpell or ParaSpell contributed to / collaborated with. +The key areas are: +- Introduction +![img7](https://user-images.githubusercontent.com/55763425/219368826-2bb5474f-a76f-4828-be15-c3274d9ae10a.png) +- Guide on importing SDK +![img8](https://user-images.githubusercontent.com/55763425/219368879-8bd4fd5a-a1f5-4417-8620-d8b279c99733.png) + +- Guide on launching local network and UI +![img10](https://user-images.githubusercontent.com/55763425/219369125-ce0756d7-49ef-437e-98b0-2336aa250137.png) + + +- Guide on executing operations in UI +![img11](https://user-images.githubusercontent.com/55763425/219368943-4115808b-1322-4551-b03a-b693bec285a2.png) + +- Guide on implementing SDK +![img12](https://user-images.githubusercontent.com/55763425/219369060-1c0c1076-65e5-4997-a1c6-b99da9f33bac.png) + + +- Important links +![img13](https://user-images.githubusercontent.com/55763425/219369013-e147d239-28a2-4701-9c16-2614b975d210.png) + +#### Architecture 🏗️ +![screenFlow](https://user-images.githubusercontent.com/55763425/198412240-e031d877-c5d8-4952-9048-2e1256ba4469.svg) + +UI is purposely designed to be as simple as possible. This guarantees, that all tasks can be done quickly and without extended searching. All necessary screens also feature notifications which will as a milestone explain be callback reactive. The loading screen is only present on the first application & network startup, once accessing the same screen after the application was loaded it will be skipped automatically. The screen serves to register necessary assets in parachain nodes. This is only required to be run once per network startup. + +SDK currently handles transfers to 42 compatible Parachains (all XCM Palletts) ([ParaSpell SDK](https://github.com/paraspell/sdk/)) and also can transfer to both Relay chains. It is easy to construct calls as is but we want to make it even easier and more developer friendly. + +#### Technology Stack 💻️ +- Vue.js +- Node.js +- Typescript +- Polkadot api libraries +- Make +- Parachain launch +- Substrate compatible nodes (For now Rococo, Pichiu(Kylin network), Bifrost & Acala) + +### Ecosystem Fit 🌳 + +There are not many XCM & XCMP related development tools released currently. We aim to aid this mostly empty space and help developers to understand XCM & XCMP as the current state-of-the-art technology by providing documentation and a user interface in which they can do development tasks more easily and faster. + +In Polkadot and Kusama ecosystem, there are few XCM related tools in development. For example Moonbeam XCM SDK was released only recently. We bring comparison table that compares our ParaSpell SDK to Moonbeam SDK +| Features | ParaSpell XCM SDK | Moonbeam XCM SDK | +| -----: | ----------- | ------------- | +| Number of packages user has to install | User needs to install only 1 package | User needs to install 2 packages | +| Support for Parachains | Already integrated for every XCM compatible pallet Link to implementation [ParaSpell SDK](https://github.com/paraspell/sdk/) | Every new node has to be added manually | +| Build pattern | Integrated as intuitive as possible | Integrated, not as intuitive to implement however | +| Support for asset pallet operations | Integrated | Not integrated | +| Support for HRMP pallet operations | Integrated users can open & close HRMP channels on their local chain (Useful feature for devs) | Not integrated | +| Support for checking details that do not change | Integrated & also be covered with some error handling eg (too little ammount being sent, not sufficient for XCM transfer) | Integrated in form of small "map" for different Tokens & Node IDs | +| Support for Axelar GMP (General message passing) that will connect Substrate with EVM chains | Planned to be implemented in the future | No data | + + + +Unlike the already mentioned "Moonbeam XCM" platform ParaSpell provides UI enhancement that uses our XCM SDK and users can try/learn technology from it. ParaSpell also includes support for 42 Substrate Parachains ([ParaSpell SDK](https://github.com/paraspell/sdk/) that have XCM pallets compared to Moonbeam XCM to which users have to implement compatible nodes manually. ParaSpell SDK only needs one package compared to Moonbeam XCM which has total of two. Compared to Moonbeam XCM which contains only XCM calls ParaSpell also contains calls that can open or close HRMP channels. We also include support for Parachains that have template pallet for XCM called polkadotXCM this pallet is a little harder to work with than xTokens, even more for inexperienced developers. + +Another comparison worth mentioning is UI vs Morph which is also enhancement of XCM UI Transfer tool +| Features | ParaSpell XCM UI | Morph | +| -----: | ----------- | ------------- | +| Focus: | Developers & users that wish to try XCM locally first | Users | +| Wiki: | Comprehensive Wiki explaining XCM, how to add assets to UI & Nodes and more implemented | Not implemented | +| Support for transfers: | In three different scenarios | In two scenarios | +| Support for local network configuration: | Fully implemented example network configuration that uses maintained Parachain-launch library | Not implemented | +| Support for HRMP channel opening/closing: | Fully implemented | Not implemented | + +Unlike the already mentioned "Morph" platform ParaSpell focuses more on developers. ParaSpell features complete network install and startup configuration in one single command. This automatization ensures, that developers do not need to do any extra tasks when they wish to run development nodes locally. ParaSpell also allows developers to open and close HRMP channels between Parachains they connected. Like "Morph", ParaSpell can also transfer fungible tokens in three scenarios. From Parachains to Relay chain, from Relay chain to Parachains & from Parachains to Parachains. + +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 entire ecosystem in our opinion. + +Our target audiences are Web3 projects and starting/current blockchain developers. +## 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, SDK 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, Slovak Republic +- **Registered Legal Entity:** Dušan Morháč ml. + +### 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 XCMP & ParaSpell project. It is published by [IEEE](https://ieeexplore.ieee.org/document/9872938). Dušan also studies Blockchain technology and had a bachelor's thesis about cross-blockchain sharing from which this idea was born. Dušan also continues research on this idea in his Master's thesis. He is actively working on [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. +![img14](https://user-images.githubusercontent.com/55763425/223093342-7d947a57-b114-4260-8999-fd4506adc76e.jpg" width="380" height="280") + +- 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 with Dušan and he delivered many of the key features SDK now offers. + +### Team Code Repos + +- https://github.com/paraspell/xcm-sdk +- https://github.com/paraspell/ui-v2 +- 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: + +[SDK](https://github.com/paraspell/xcm-sdk) is currently released into main and is in version that is fully operable. There are still some tweaks we plan to add and make, they are mentioned below. [UI-V2](https://github.com/paraspell/ui-v2) currently runs on state-of-the-art technology version VueJS 3 and newest version of Nuxt. It deprecated V1 and introduced much smoother interface and modules brought from subscaffold template ParaSpell contributed to. [Docs](https://github.com/paraspell/docs) are currently in ready state but there is still some tweaking to do. + +Sidenote: We have recently developed article about Polkadot & Paraspell called Enhancing XCMP Interoperability Across Polkadot Paraverse and it was accepted to International IEEE ICBC 2023 conference held in Dubai. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 1 FTE +- **Total Costs:** 10,000 USD + +### Milestone 1 - Phase 3, make XCM SDK more efficient, add new nodes & rework Localhost network in UI + +- **Estimated duration:** 2 months ⌛️ +- **FTE:** 1 +- **Costs:** 10,000 USD 💰️ + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a usage explanation in readme.md | +| 0c. | Testing and Testing Guide | SDK Core UNIT tests will be provided for xTokens Pallet, HRMP pallet, polkadotXCM pallet| +| 0d. | Docker | Docker file that allows to test ParaSpell SDK through ParaSpell UI will be provided. | +| 0e. | Create Medium article about development of Phase 3 ParaSpell | Add article covering new features & improvements brought in Phase3 | +| 1. | Merge currencyId & currency in XCM Transfers | Merge currency ID and currency symbol into one so user do not need to enther both. Raised in issue: https://github.com/paraspell/xcm-sdk/issues/16 | +| 2.a | Add support for new compatible nodes in DMP Scenario (Downwards message passing) | Check for new Parachain support & update Parachains, that have new compatibility with other Parachains in DMP Scenario & Update list of [compatible Parachains](https://github.com/paraspell/xcm-sdk/blob/main/docs/supportedNodes.md) accordingly | +| 2.b | Add support for new compatible nodes in UMP Scenario (Upwards message passing) | Check for new Parachain support & update Parachains, that have new compatibility with other Parachains in UMP Scenario & Update list of [compatible Parachains](https://github.com/paraspell/xcm-sdk/blob/main/docs/supportedNodes.md) accordingly | +| 2.c | Add support for new compatible nodes in HRMP Scenario (Horizontall message passing) | Check for new Parachain support & update Parachains, that have new compatibility with other Parachains in HRMP Scenario & Update list of [compatible Parachains](https://github.com/paraspell/xcm-sdk/blob/main/docs/supportedNodes.md) accordingly| +| 3. | Rework Utils.ts to remove huge switch that constructs message | Rework construct XCM message function to not have switch and be more efficient in construction - [link](https://github.com/paraspell/xcm-sdk/blob/main/src/utils.ts#L344) | +| 4.a | Deprecate Parachain-launch & replace it with Zombienet I | Replace network startup configuration from Parachain-launch library into state of the art technology called Zombienet [link1](https://github.com/paraspell/ui-v2/blob/main/Makefile#L5), [link2](https://github.com/paraspell/ui-v2/blob/main/paraspell-network-config.yml)| +| 4.b | Deprecate Parachain-launch & replace it with Zombienet II | Update ParaSpell Docs | +| 5. | Add suggestions we received in our previous grant evaluations (If not added already) | Add suggestions from our phase1 and phase2 proposal evaluations if they were not added already | + +## Future Plans 🔭 + +Once everything will be implemented according to the proposed plan application will still be under constant improvement as technology will progress. For example, once the XCMP protocol will be released we wish to deprecate the HRMP protocol we currently use for channels. + +In a long run, we also want to improve design of the UI, add new features that can be useful for developers and support for new nodes. + +Project goal is that SDK will serve dApp developers and UI will teach new substrate developers to use XCM and will serve to existing substrate developers to test their freshly baked Parachains. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Personal recommendation + +##### Project achievements in chronological order ⌛️ + +- 📙 Article about project created & presented on 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 a 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) +- ⭐️ [Astar](https://astar.network/) XCM bounty Polkadot hackathon Latam Bounty [link](https://github.com/AstarNetwork/AstarBounties/pull/17) +- 🔭 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 [links TBA] diff --git a/applications/Parallel.md b/applications/Parallel.md index 2fbb92abe21..d783bb68e9c 100644 --- a/applications/Parallel.md +++ b/applications/Parallel.md @@ -1,8 +1,8 @@ -# Parallel Finance Open Grant Proposal +# Parallel Finance -- **Project Name:** Parallel Finance -- **Team Name:** Parallel -- **Payment Address:** 0x17816E9A858b161c3E37016D139cf618056CaCD4 +- **Project Name:** Parallel Finance +- **Team Name:** Parallel +- **Payment Address:** 0x17816E9A858b161c3E37016D139cf618056CaCD4 ## Project Overview :page_facing_up: @@ -12,27 +12,27 @@ Parallel finance is a decentralized lending/borrowing and staking protocol built Our platform offers a few key features and benefits: -- **Lending and borrowing**: users can lend and borrow assets based on interest rates. -- **Staking**: users can participate in Polkadot’s network validation and earn rewards. -- **Earning double interests**: users can choose to stake and lend out their tokens simultaneously based on our new approach. -- **Powered by Substrate**: our platform benefits from the speed, resiliency and convenient upgradability of Polkadot. +- **Lending and borrowing**: users can lend and borrow assets based on interest rates. +- **Staking**: users can participate in Polkadot’s network validation and earn rewards. +- **Earning double interests**: users can choose to stake and lend out their tokens simultaneously based on our new approach. +- **Powered by Substrate**: our platform benefits from the speed, resiliency and convenient upgradability of Polkadot. Our project utilizes substrate framework and is built on top of polkadot parachain ecosystem: -- We built the core interests model and functionalities on substrate runtime -- We enabled off-chain worker to query the current price feed of DOT and other tokens -- We will build cross-chain interoperability using XCMP protocol in the near future +- We built the core interests model and functionalities on substrate runtime +- We enabled off-chain worker to query the current price feed of DOT and other tokens +- We will build cross-chain interoperability using XCMP protocol in the near future **Why are we building Parallel Finance?** -- We decided to pick this idea because of the rising demand for decentralized lending protocols on Polkadot and Kusama, as well as the lack of token liquidity that comes with staking on the mainnet. We estimate that 50% of all existing DOT and KSM tokens will be staked for blockchain validation with an estimated staking APY of 10-20%. However, the DOT and KSM tokens will lose their liquidity once they are staked to validate the network. Institutions and large token holders have high incentives to use our platform since it will allow them to not only participate in staking, but also generate additional profits through lending, and allow them to use their DOTs and KSMs as payment, or trading assets. +- We decided to pick this idea because of the rising demand for decentralized lending protocols on Polkadot and Kusama, as well as the lack of token liquidity that comes with staking on the mainnet. We estimate that 50% of all existing DOT and KSM tokens will be staked for blockchain validation with an estimated staking APY of 10-20%. However, the DOT and KSM tokens will lose their liquidity once they are staked to validate the network. Institutions and large token holders have high incentives to use our platform since it will allow them to not only participate in staking, but also generate additional profits through lending, and allow them to use their DOTs and KSMs as payment, or trading assets. ### Project Details ##### MVP links -- Testnet demo: https://parallel.fi/#/ -- Video demo: https://youtu.be/lgQX9rELpL8 +- Testnet demo: https://parallel.fi/#/ +- Video demo: https://youtu.be/lgQX9rELpL8 #### Mockups and UI components @@ -69,78 +69,79 @@ The lending protocol was inspired by compound protocol and our blockchain soluti ##### What your project is _not_ or will _not_ provide or implement -- Our team does not plan on implementing the support for other tokens besides the native DOT and KSM tokens and Stable Coin at the initial launch in order to reduce the risks in cross-collaterals -- We will not implement a decentralized exchange by ourselves. Instead, we will be focusing on building the lending/borrowing and staking protocol. +- Our team does not plan on implementing the support for other tokens besides the native DOT and KSM tokens and Stable Coin at the initial launch in order to reduce the risks in cross-collaterals +- We will not implement a decentralized exchange by ourselves. Instead, we will be focusing on building the lending/borrowing and staking protocol. ### Ecosystem Fit -- **Where and how does your project fit into the ecosystem?** We are aiming to offer the first decentralized lending/borrowing and staking protocol in the Polkadot and Kusama ecosystem as a DeFi and a parachain. -- **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** Our target audience are the DOT and KSM token holders who are looking to participate in lending/borrowing, staking and unlocking liquidity for their staked tokens, or generating "double interests" returns by lending and staking simultaneously. This audience would include retail, institutional and large token holders, traders (arbitrage opportunities in DeFi) and network validators. In general, large token holders will have a higher incentive to join the platform earlier as the exchange rate will be more favorable. -- **What need(s) does your project meet?** Our project helps generate additional interests for token holders, provide assets for borrowing and unlock liquidity for token stakers who can use staked tokens (ex: xDOT) to trade, lend or use as payment. -- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** - - **If so, how is your project different?** Compound has been a successful and proven model for lending and borrowing assets in a decentralized manner in the Ethereum ecosystem. However, Compound doesn't offer staking services, and there is currently no decentralized lending/borrowing solution launched in the Polkadot ecosystem. Acala Network does offer staking services, but doesn't offer lending/borrowing services. From that perspective, we are a unique solution that combines both services and offers additional interests to our users. - - **If not, are there similar projects in related ecosystems?** We have not yet found a project that will be focusing on generating double interests for token holders through lending and staking. +- **Where and how does your project fit into the ecosystem?** We are aiming to offer the first decentralized lending/borrowing and staking protocol in the Polkadot and Kusama ecosystem as a DeFi and a parachain. +- **Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)?** Our target audience are the DOT and KSM token holders who are looking to participate in lending/borrowing, staking and unlocking liquidity for their staked tokens, or generating "double interests" returns by lending and staking simultaneously. This audience would include retail, institutional and large token holders, traders (arbitrage opportunities in DeFi) and network validators. In general, large token holders will have a higher incentive to join the platform earlier as the exchange rate will be more favorable. +- **What need(s) does your project meet?** Our project helps generate additional interests for token holders, provide assets for borrowing and unlock liquidity for token stakers who can use staked tokens (ex: xDOT) to trade, lend or use as payment. +- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** + - **If so, how is your project different?** Compound has been a successful and proven model for lending and borrowing assets in a decentralized manner in the Ethereum ecosystem. However, Compound doesn't offer staking services, and there is currently no decentralized lending/borrowing solution launched in the Polkadot ecosystem. Acala Network does offer staking services, but doesn't offer lending/borrowing services. From that perspective, we are a unique solution that combines both services and offers additional interests to our users. + - **If not, are there similar projects in related ecosystems?** We have not yet found a project that will be focusing on generating double interests for token holders through lending and staking. ## Team :busts_in_silhouette: ### Team members -- Name of team leader: Yubo Ruan -- Names of team members: Remi Gai, Zhou Yang, Li Pai, Cheng Jiang, Hai Yi +- Name of team leader: Yubo Ruan +- Names of team members: Remi Gai, Zhou Yang, Li Pai, Cheng Jiang, Hai Yi ### Contact -- **Contact Name:** Yubo Ruan -- **Contact Email:** yubo@parallel.fi -- **Website:** www.parallel.fi +- **Contact Name:** Yubo Ruan +- **Contact Email:** yubo@parallel.fi +- **Website:** www.parallel.fi ### Legal Structure (we are in the process of registering the legal entity) -- **Registered Address:** N/A -- **Registered Legal Entity:** N/A +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A ### Team's experience -- **Yubo Ruan**: Yubo is currently a venture investor at Polychain Capital and 8 Decimal Capital. Yubo previously worked at TrustToken as a solidity engineer and helped build the TrueFi uncollateralized lending protocol. Additionally, Yubo started Alisimba Technology with wide range of media coverage in China and was granted many national patents and innovation awards. Yubo studied computer science at Stanford University. -- **Yang Zhou**: Yang is a senior blockchain engineer at Elastos and its Gelaxy group. At Elastos, Yang contributed to the cli tool, cross-chain protocol, and merged mining specification. Additionally, Yang was the point of contact with the world's top mining pool (F2Pool, BTCPool, ANTPool, and Huobipool), and successfully launched the Elastos mining business. Yang also worked at large software tech companies and has 9 years of development experience. -- **Remi Gai**: Remi is a software engineer with a background in product management, entrepreneurship and venture capital, and currently works at Microsoft. Previously, Remi worked as an early stage investor at 8 Decimal Capital, a crypto/blockchain focused fund, and was the co-founder of Bitsystems, a blockchain development firm based in Cambridge, Massachusetts. -- **Lipai Zhu**: Lipai has 4 years of experience in blockchain. For the past 2 years, Li Pai has been working as a blockchain engineer at JianXinZhuHe technology at Shenzhen and focuses on consortium blockchain. Prior, Lipai studied BitCoin, Ethereum and Solidity and won a prize at BSN Second developer competition and a grand prize at the 4th China Blockchain Development Competition (In Competition, his duty is design smart contract and develop it). -- **Cheng Jiang**: Cheng Jiang is a senior Fullstack Developer at Ubudu, experienced in Fullstack development, Network topology and Indoor Location System Algorithms. -- **Hai Yi**: Hai Yi has 4 years experience in software engineering. He was a former software engineer at Swissborg, and trading product associate at the Bank of Montreal. Hai Yi holds a BSc in Computer Science degree from the University of Waterloo). +- **Yubo Ruan**: Yubo is currently a venture investor at Polychain Capital and 8 Decimal Capital. Yubo previously worked at TrustToken as a solidity engineer and helped build the TrueFi uncollateralized lending protocol. Additionally, Yubo started Alisimba Technology with wide range of media coverage in China and was granted many national patents and innovation awards. Yubo studied computer science at Stanford University. +- **Yang Zhou**: Yang is a senior blockchain engineer at Elastos and its Gelaxy group. At Elastos, Yang contributed to the cli tool, cross-chain protocol, and merged mining specification. Additionally, Yang was the point of contact with the world's top mining pool (F2Pool, BTCPool, ANTPool, and Huobipool), and successfully launched the Elastos mining business. Yang also worked at large software tech companies and has 9 years of development experience. +- **Remi Gai**: Remi is a software engineer with a background in product management, entrepreneurship and venture capital, and currently works at Microsoft. Previously, Remi worked as an early stage investor at 8 Decimal Capital, a crypto/blockchain focused fund, and was the co-founder of Bitsystems, a blockchain development firm based in Cambridge, Massachusetts. +- **Lipai Zhu**: Lipai has 4 years of experience in blockchain. For the past 2 years, Li Pai has been working as a blockchain engineer at JianXinZhuHe technology at Shenzhen and focuses on consortium blockchain. Prior, Lipai studied BitCoin, Ethereum and Solidity and won a prize at BSN Second developer competition and a grand prize at the 4th China Blockchain Development Competition (In Competition, his duty is design smart contract and develop it). +- **Cheng Jiang**: Cheng Jiang is a senior Fullstack Developer at Ubudu, experienced in Fullstack development, Network topology and Indoor Location System Algorithms. +- **Hai Yi**: Hai Yi has 4 years experience in software engineering. He was a former software engineer at Swissborg, and trading product associate at the Bank of Montreal. Hai Yi holds a BSc in Computer Science degree from the University of Waterloo). ### Team Code Repos -- Backend: https://github.com/parallel-finance/parallel -- Frontend: https://github.com/parallel-finance/hackathon-2021-spring/tree/main/teams/22-Parallel/src/parallel-dapp +- Backend: https://github.com/parallel-finance/parallel +- Frontend: https://github.com/parallel-finance/hackathon-2021-spring/tree/main/teams/22-Parallel/src/parallel-dapp ### Team LinkedIn Profiles -- https://www.linkedin.com/in/yubo-ruan/ -- https://www.linkedin.com/in/remigai/ -- https://www.linkedin.com/in/cheng-jiang-2a414020a/ -- https://www.linkedin.com/in/haiyi-zhong-6274108b/?originalSubdomain=ca -- https://www.linkedin.com/in/zhulipai/ -- https://www.linkedin.com/in/yz89/ +- https://www.linkedin.com/in/yubo-ruan/ +- https://www.linkedin.com/in/remigai/ +- https://www.linkedin.com/in/cheng-jiang-2a414020a/ +- https://www.linkedin.com/in/haiyi-zhong-6274108b/?originalSubdomain=ca +- https://www.linkedin.com/in/zhulipai/ +- https://www.linkedin.com/in/yz89/ ## Development Roadmap :nut_and_bolt: ### Overview + * **Total Estimated Duration:** 4 months -* **Full-time equivalent (FTE):** 4 FTE -* **Total Costs:** 9k USD +- **Full-time equivalent (FTE):** 4 FTE +- **Total Costs:** 9k USD ### Milestone 1 — Implement Cross-chain support for DOT and KSM -- **Estimated Duration:** 8 weeks -- **FTE:** 1.8 -- **Costs:** 4000 USD +- **Estimated Duration:** 8 weeks +- **FTE:** 1.8 +- **Costs:** 4000 USD The major deliverable of for this milestone: -- Implement a multi-assets lending protocol. -- Support automatic liquidation by using an off-chain worker. +- Implement a multi-assets lending protocol. +- Support automatic liquidation by using an off-chain worker. | Number | Deliverable | Specification | | -----: | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -155,22 +156,22 @@ The major deliverable of for this milestone: | 5. | User Testing | We will conduct user testing to improve our product's UI and UX, to ensure that the borrowing and lending functionalities are intuitive. Initially, we will conduct qualitative user testing by observing 10-15 users who will use the v1 platform and provide a summary of the findings and improvements made based on insights. | Other: -* We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). +- We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). ### Milestone 2 — Enable Staking for DOT and KSM -- **Estimated Duration:** 8 weeks -- **FTE:** 2.2 -- **Costs:** 5000 USD +- **Estimated Duration:** 8 weeks +- **FTE:** 2.2 +- **Costs:** 5000 USD The major deliverable of for this milestone: -- Implement the modules that allow for staking functionality, which includes - - Exchange Rate - - 28 days locking period for unstaking tokens - - Slashing scenarios - - Relay tokens to validators -- Users will be able to stake DOT tokens, and receives xDOT in return. xDOT will then start accruing interests from staking and also be used for lending or transfered elsewhere for payment or trading. Similarly, staked KSM will be converted to xKSM with the same features as xDOT. +- Implement the modules that allow for staking functionality, which includes + - Exchange Rate + - 28 days locking period for unstaking tokens + - Slashing scenarios + - Relay tokens to validators +- Users will be able to stake DOT tokens, and receives xDOT in return. xDOT will then start accruing interests from staking and also be used for lending or transfered elsewhere for payment or trading. Similarly, staked KSM will be converted to xKSM with the same features as xDOT. | Number | Deliverable | Specification | | -----: | ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -187,32 +188,32 @@ The major deliverable of for this milestone: | 6. | User Testing | We will conduct user testing to improve our product's UX and UI, to ensure that the borrowing and lending functionalities are intuitive. Initially, we will conduct qualitative user testing by observing 10-15 users use the v1 platform and provide a summary of the findings and improvements made based on insights. | Other: -* We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). +- We will implement more quantitative user testing with A/B tests, web analytics, and heatmap once we have more adoption (>100-200 DAU) in order to get more significant insights (not part of v1 deliverables). ## Future Plans **Community Development**: -- In the short term, we will focus on acquiring the early users for our platform, who are large token holders and institutions. The exchange rate will be lower initially as the pool size and number of blocks are lower, so there's a strong incentive for larger players to deposit their tokens early on. As the Kusama and Polkadot mainnets are approaching, we will be forming partnership with validators who might be interested in forming partnerships or use our platform to gain liquidity on their staked tokens. -- We will frequently post on social media (Twitter, Medium, Youtube) to provide development news and video tutorials regarding our platform. We will also work with influencers, who can break down complex concepts and provide clear guidance to the mainstream users on how to use our platform. -- Our long term plan is to provide a suite of products that will allow users to earn superior interests with their assets on our Defi platform, as we truly believe in the benefits of decentralization and allowing more mainstream investors to participate in the financial economy. +- In the short term, we will focus on acquiring the early users for our platform, who are large token holders and institutions. The exchange rate will be lower initially as the pool size and number of blocks are lower, so there's a strong incentive for larger players to deposit their tokens early on. As the Kusama and Polkadot mainnets are approaching, we will be forming partnership with validators who might be interested in forming partnerships or use our platform to gain liquidity on their staked tokens. +- We will frequently post on social media (Twitter, Medium, Youtube) to provide development news and video tutorials regarding our platform. We will also work with influencers, who can break down complex concepts and provide clear guidance to the mainstream users on how to use our platform. +- Our long term plan is to provide a suite of products that will allow users to earn superior interests with their assets on our Defi platform, as we truly believe in the benefits of decentralization and allowing more mainstream investors to participate in the financial economy. **Product Development**: -- This is our tentative development roadmap for the rest of this year: +- This is our tentative development roadmap for the rest of this year: ![image](https://user-images.githubusercontent.com/56744348/111891918-94ebaa80-89c4-11eb-8707-a16b33e7b54c.png) ## Additional Information :heavy_plus_sign: -- We are a team that met and formed during the March 2021 Polkadot Hackathon in Shanghai. Our team members are both in the US and China, and come from a strong engineering background (crypto/blockchain, startup, traditional tech company), product management and financial background (venture capital, Defi). We were able to deliver our proof of concept within a month, and earned third place at the Hackathon. +- We are a team that met and formed during the March 2021 Polkadot Hackathon in Shanghai. Our team members are both in the US and China, and come from a strong engineering background (crypto/blockchain, startup, traditional tech company), product management and financial background (venture capital, Defi). We were able to deliver our proof of concept within a month, and earned third place at the Hackathon. -- We are currently still in the process of creating our white paper, but you can find more details about our documentation on our gitbook: https://docs.parallel.fi/. +- We are currently still in the process of creating our white paper, but you can find more details about our documentation on our gitbook: https://docs.parallel.fi/. -- Email: team@parallel.fi -- Website: parallel.fi -- Twitter: https://twitter.com/ParallelFi -- Medium: https://medium.com/@parallelfinance -- LinkedIn: https://www.linkedin.com/company/parallel-finance/ -- Unofficial white paper: https://docs.parallel.fi/ -- Testnet demo: https://parallel.fi/#/app -- Video demo (Hackathon March 2021): https://youtu.be/lgQX9rELpL8 +- Email: team@parallel.fi +- Website: parallel.fi +- Twitter: https://twitter.com/ParallelFi +- Medium: https://medium.com/@parallelfinance +- LinkedIn: https://www.linkedin.com/company/parallel-finance/ +- Unofficial white paper: https://docs.parallel.fi/ +- Testnet demo: https://parallel.fi/#/app +- Video demo (Hackathon March 2021): https://youtu.be/lgQX9rELpL8 diff --git a/applications/Plus-follow-up.md b/applications/Plus-follow-up.md index 91322fed5e5..254a7b50718 100644 --- a/applications/Plus-follow-up.md +++ b/applications/Plus-follow-up.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkadot js plus / Nomination pools -- **Project Name:** Polkadot js plus / Nomination pools - **Team Name:** Polkadot js plus - **Payment Address:** 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 @@ -11,7 +10,7 @@ This is an application for a follow-up grant for providing POOL STAKING in "[Plus:Polkadot js Plus Extension](https://github.com/w3f/Grants-Program/pull/778)". -# ![polkadot{.js} plus extension intro](https://github.com/Nick-1979/polkadot-Js-Plus-extension/blob/master/packages/extension-plus/docs/intro.png) +# ![polkadot\{.js} plus extension intro](https://github.com/Nick-1979/polkadot-Js-Plus-extension/blob/master/packages/extension-plus/docs/intro.png) ### Overview @@ -36,9 +35,9 @@ Recently, Parity Technologies staking team released a new pallet, named **"Nomin With the new functionality the stakers on Kusama/Polkadot will have two options to stake their tokens, hence when click on easy staking in Polkadot js plus extension, solo or pool staking can be chosen. -# ![polkadot{.js} plus extension accounts](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/accounts.png) +# ![polkadot\{.js} plus extension accounts](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/accounts.png) -# ![polkadot{.js} plus extension staking index](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/stakingIndex.png) +# ![polkadot\{.js} plus extension staking index](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/stakingIndex.png) With Pool staking, stakers (delegators) with a small amount of tokens (e.g., 1 DOT) can pool their funds together and act as a single nominator. The earnings of the pool are split pro rata to a delegator's stake in the bonded pool. @@ -51,21 +50,21 @@ Ther following features will be available in pool staking: Where a delegator can easily contribute in pool staking automatically, and confirm it by entering the account password: -# ![polkadot{.js} plus extension pool stake](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStake.png) +# ![polkadot\{.js} plus extension pool stake](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStake.png) -# ![polkadot{.js} plus extension pool stake confirm](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/confirmPoolStake.png) +# ![polkadot\{.js} plus extension pool stake confirm](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/confirmPoolStake.png) Similarly unstaking can be done, where unlocking bonds will be redeemable after a while depending on the chain: -# ![polkadot{.js} plus extension pool unstake confirm](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/confirmPoolUnstake.png) +# ![polkadot\{.js} plus extension pool unstake confirm](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/confirmPoolUnstake.png) Pools information along with its roles and accounts can be presented in pooltab: -# ![polkadot{.js} plus extension pool staking pool tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStakingPoolTab.png) +# ![polkadot\{.js} plus extension pool staking pool tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStakingPoolTab.png) The account(s) with root and nominator role can nominated validators for the deligated stashId, the nominated validators can be depicted in the nominations tab: -# ![polkadot{.js} plus extension pool staking nominations tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStakingNominationsTab.png) +# ![polkadot\{.js} plus extension pool staking nominations tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStakingNominationsTab.png) The general information that every staker/deligators needs to know can be summarized in info tab: -# ![polkadot{.js} plus extension pool staking info tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStakingInfoTab.png) +# ![polkadot\{.js} plus extension pool staking info tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/poolStakingInfoTab.png) There would be also modules for manual pool selection/creation, manual validator selection, pool details information including pool's members' information, etc. diff --git a/applications/Plus-social-recovery-wallet.md b/applications/Plus-social-recovery-wallet.md index 8cf666bb3c6..1ca29f8e99f 100644 --- a/applications/Plus-social-recovery-wallet.md +++ b/applications/Plus-social-recovery-wallet.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkadot js plus / Social Recovery Wallet -- **Project Name:** Polkadot js plus / Social Recovery Wallet - **Team Name:** Polkadot js plus - **Payment Address:** 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 @@ -11,7 +10,7 @@ This is a proposal for the RFP titled [Social Recovery Wallet](https://github.com/w3f/Grants-Program/blob/master/rfps/open/social-recovery-wallet.md), and in other words a follow-up grant for providing Social Recovey in "[Plus:Polkadot js Plus Extension](https://github.com/w3f/Grants-Program/pull/778)" -# ![polkadot{.js} plus extension intro](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/intro.png) +# ![polkadot\{.js} plus extension intro](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/intro.png) ### Overview @@ -37,11 +36,11 @@ Based on the [Social Recovery Wallet](https://github.com/w3f/Grants-Program/blob With the new functionality the token holders will be able to make their accounts Recoverable. Almost all required information will be saved on-chain, utilizing Substrate/Recovery-Pallet. -# ![polkadot{.js} plus extension make recoverable](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/makeRecoverable.png) +# ![polkadot\{.js} plus extension make recoverable](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/makeRecoverable.png) and when you open the accounts page, a green shield icon indicates which account is already recoverable. -# ![polkadot{.js} plus extension recoverable icon](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/accountPage.png) +# ![polkadot\{.js} plus extension recoverable icon](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/accountPage.png) Ther following features will be available as Social recovery wallet: @@ -56,26 +55,26 @@ Ther following features will be available as Social recovery wallet: After an account holder determined their friends and set recovery delay and threshold, can make the account recoverable by confirming it using the account password: -# ![polkadot{.js} plus extension confirm making recoverable](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/confirmMakeRecoverable.png) +# ![polkadot\{.js} plus extension confirm making recoverable](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/confirmMakeRecoverable.png) Similarly the user can remove recovery for a recoverable account using remove recovery tab: -# ![polkadot{.js} plus extension remove recovery](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/removeRecovery.png) +# ![polkadot\{.js} plus extension remove recovery](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/removeRecovery.png) To rescue a lost account, we have two identities, a rescuer and the lost account's friends, who can help to rescue the lost account: -# ![polkadot{.js} plus extension rescue tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/recoverTab.png) +# ![polkadot\{.js} plus extension rescue tab](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/recoverTab.png) A rescuer should start by intiating the recovery process, but usually when you lost your account you hardly remember the acount Id, hence, it should be possible to find the lost account using it's on-chain identity: -# ![polkadot{.js} plus extension iniTiate recovery](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/initiateRecovery.png) +# ![polkadot\{.js} plus extension iniTiate recovery](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/initiateRecovery.png) When a malicious rescuer initiates the recovery for a lost account, we need to set an alert for the lost account, as can be seen below as a beating red shield . -# ![polkadot{.js} plus extension red alert](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/accoutPageWithRedAlert.png) +# ![polkadot\{.js} plus extension red alert](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/accoutPageWithRedAlert.png) Therfore, the lost account can close the recovery to protect their account. -# ![polkadot{.js} plus extension close recovery](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/closeRecovery.png) +# ![polkadot\{.js} plus extension close recovery](https://raw.githubusercontent.com/Nick-1979/PolkadotJsPlusPictures/main/socialRecovery/closeRecovery.png) diff --git a/applications/Plus.md b/applications/Plus.md index be37264e555..22d9c0fc462 100644 --- a/applications/Plus.md +++ b/applications/Plus.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Plus: Polkadot js plus extension -- **Project Name:** Plus: Polkadot js plus extension - **Team Name:** Kami Ekbatanifard - **Payment Address:** 0xa4Eff15578D1450912DED08c85679F453C45A710 (DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 diff --git a/applications/Plutonication.md b/applications/Plutonication.md new file mode 100644 index 00000000000..8d16f495734 --- /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 Polkadotjs extension .- D +end + +subgraph Phone +W["Mobile wallet + Private key always stays here"] +end + +S -- Receive signed payload --> E +E -- Send extrinsic payload --> S + +S -- Receive extrinsic payload --> W +W -- Send signed payload --> S + +E -. Scan QR code for establishing connection .-> W; +``` + +#### An overview of the technology stack to be used + +1) Plutonication server (Python): Flask, Flask-SocketIO +2) Mobile Wallet: https://github.com/rostislavLitovkin/plutowallet +3) Plutonication Native (C#): SocketIOClient, Substrate.NetApi +4) Plutonication Native (TS): socket.io-client, Polkadot.js +5) Plutonication Extension: socket.io-client, Polkadot.js extension + +#### Documentation of core components, protocols, architecture, etc. to be deployed + +##### Plutonication Server +- Used for reliable establishing of connection. +- Passes payloads between Wallets and dApps. + +##### Mobile Wallet +- Has access to the private key +- signs the payloads and sends them back to the dApp. +- Never exposes the private key + +##### dApp +- needs to have access to either: Plutonication Native / Plutonication Extension + +##### Plutonication Native +- A simple package that allows the dApp get connected with the Mobile Wallet. +- Connects the dApp with the Plutonication server. +- Helps to generate a QR code for the Wallet to establish the connection. + +##### Plutonication Extension +- a polkadot.js extension that works with any existing dApp that supports polkadot.js extension. +- Connects the dApp with the Plutonication server. +- Generate a QR code for the Wallet to establish the connection. + +#### PoC/MVP or other relevant prior work or research on the topic +- Second place at Polkadot Global Series: Europe edition 2023 hackathon in Web3 and Tooling category. +- https://github.com/cisar2218/Plutonication +- Plutonication is integrated to: https://github.com/rostislavLitovkin/plutowallet +- https://github.com/rostislavLitovkin/plutonicationextension + +#### What your project is _not_ or will _not_ provide or implement + +- Any improvements to PlutoWallet appart from the things needed for Plutonication to work in the PlutoWallet. + +- Although it is planned support Kotlin and Swift programming languages as well, it is not part of this grant proposal. + +- We are certainly willing to make PRs to other popular dApps to utilise Plutonication, it is also not part of this grant proposal. We would be willing to do a follow-up grant or get a treasury funding to make the PRs. + +### Ecosystem Fit + +Help us locate your project in the Polkadot/Substrate/Kusama landscape and what problems it tries to solve by answering each of these questions: + +#### Where and how does your project fit into the ecosystem? + +- Our project is comparable to WalletConnect, which was also our inspiration. + +##### [WalletConnect](https://walletconnect.com/) +- When we started making our first prototypes in February, WalletConnect was not available in the Polkadot Ecosystem yet. +Even thought they have taken a lot of time and had a lot more experience then us, they were unable to make quick and elegant deliveries. +WalletConnect still is not supported by most of the dApps. We think we can do better. Actually, we already did. + +- We made a Plutonication Extension, which already allows you to interact with existing dApps, even though they have not implemented the Plutonication standard directly. This can be a perfect middle ground during the transition of popularizing the Plutonication. Even if the user wanted to use a new niche dApp, they can do so with Plutonication. + +- Wallet connect is also only supported in javascript. We want to make Plutonication available in more languages, including a very popular C# language, which is mostly used for game development. We will make web3 gaming possible on game consoles, thanks to the Plutonication. + +- WalletConnect's server solution (also known as WalletConnect cloud) is not opensourced. We want to be open to everybody and fully opensourced. + +##### [SubConnect](https://github.com/Koniverse/SubConnect) +- This is a great aggregation of wallets. This certainly improves the UX and simplifies the development for developers. However, it is not trying to do the same thing as Plutonication. Plutonication tries to achieve connection between 2 different platforms (like mobile wallet on Android and dApp on web on Windows). + +- It may be certainly a good idea to talk to SubWallet to implement Plutonication into the SubConnect solution. + +##### [Tesseract](https://github.com/tesseract-one/Tesseract.rs) + +- Tesseract is a great solution for connecting a wallet and a dApp together on a single device. However, Plutonication allows wallets and dApps to be connected across different devices. + +##### [@talismn/connect](https://github.com/TalismanSociety/talisman-connect) + +- This is similar to SubConnect. Once again, we try to solve a completely different problem. + +#### Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? + +- dApps developers - To integrate the Plutonication in their dApps. We will ensure that the developers will receive a good documentation. + +- Wallet developers - We are welcoming other wallets to use the Plutonication. We would like to help them make this possible. + +- Users - In the end, it will be mainly used by mobile focused users. They will be able to interact with web3 apps on unusual platforms, like game consoles, smartwatches ... + +#### What need(s) does your project meet? + +- You are unable securely interact with dApps on gaming consoles, smartwatches and other unusual platforms. Without Plutonication, you would have to expose your private key, which is very unsafe. + +- You can also interact with existing web dApps with your mobile wallet. Again, you do not need to expose your private key to multiple places (in this case browser extension wallet), which would be very unsafe. + +#### Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? + +- Yes, WalletConnect. + +#### If so, how is your project different? + +- We support more programming languages. We also have a browser extension that enables Plutonication on existing dApps. + +- WalletConnect also mainly focuses on Ethereum ecosystem. We are focusing only on Polkadot. + +## Team :busts_in_silhouette: + +### Team members + +#### Name of team leader: + +Rostislav Litovkin + +#### Names of team members: + +Valentina Gómez + +Dušan Jánsky + +### Contact + +- **Contact Name:** Rostislav Litovkin +- **Contact Email:** rostislavlitovkin@gmail.com +- **Website:** https://github.com/cisar2218/Plutonication + +### Legal Structure + +- **Registered Address:** Píškova 1946/12, 155 00, Prague, Czech republic +- **Registered Legal Entity:** None + +### Team's experience + +#### [Rostislav Litovkin](http://rostislavlitovkin.pythonanywhere.com/aboutme) +- Alumnus at Polkadot Blockchain Academy 2023 in Berkeley +- Experienced .net MAUI developer, e.g.: + - [Galaxy Logic Game](https://github.com/RostislavLitovkin/galaxylogicgamemaui) (successful game for watches and mobiles, 50k+ downloads) +- Frontend developer at [Calamar explorer](https://calamar.app/) +- Successful student at Polkadot DevCamp #2 +- Successful student at [Solana Summer School](https://ackeeblockchain.com/school-of-solana) +- Polkadot Global Series 2023 (Europe) - second place +- Audience choice prize at EthPrague 2023 + +#### Valentina Gómez +- Alumnus at Polkadot Blockchain Academy 2023 - Berkeley. +- Full stack web developer in TeamClass. +- Financial Engineer + +#### Dušan Jánsky +- Alumnus at Polkadot Blockchain Academy 2023 in Berkeley +- Student at Faculty of Electrical Engineering Czech Technical University in Prague - Opens Informatics (specialization in computer games and computer graphics) +- Fullstack developer at [Universal Scientific Technologies](https://www.ust.cz/) +- Polkadot Global Series 2023 (Europe) - second place + +#### If anyone on your team has applied for a grant at the Web3 Foundation previously, please list the name of the project and legal entity here. + +Rostislav Litovkin helped with **Calamar.app - TopMonks s.r.o** + +### Team Code Repos + +- https://github.com/ThunderFly-aerospace/thumby +- https://github.com/topmonks/calamar +- https://github.com/RostislavLitovkin/GalaxyLogicGameMAUI +- https://github.com/RostislavLitovkin/Uniquery.Net + +#### Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. + +- https://github.com/cisar2218 +- https://github.com/rostislavlitovkin + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/dusan-jansky-6aab69239/ +- https://www.linkedin.com/in/valentinaga1/ + +## Development Status :open_book: + +If you've already started implementing your project or it is part of a larger repository, please provide a link and a description of the code here. In any case, please provide some documentation on the research and other work you have conducted before applying. This could be: + +- The idea was already tested by WalletConnect. Now, we are expanding it further in the Polkadot ecosystem. + +- We have already made working MVPs which can be found here: + + - https://github.com/cisar2218/Plutonication + + - https://github.com/rostislavLitovkin/plutowallet + + - https://github.com/rostislavLitovkin/plutonicationextension + +## Development Roadmap :nut_and_bolt: + +This section should break the development roadmap down into milestones and deliverables. To assist you in defining it, we have created a document with examples for some grant categories [here](../docs/Support%20Docs/grant_guidelines_per_category.md). Since these will be part of the agreement, it helps to describe _the functionality we should expect in as much detail as possible_, plus how we can verify and test that functionality. Whenever milestones are delivered, we refer to this document to ensure that everything has been delivered as expected. + +Below we provide an **example roadmap**. In the descriptions, it should be clear how your project is related to Substrate, Kusama or Polkadot. We _recommend_ that teams structure their roadmap as 1 milestone ≈ 1 month. + +> :exclamation: If any of your deliverables is based on somebody else's work, make sure you work and publish _under the terms of the license_ of the respective project and that you **highlight this fact in your milestone documentation** and in the source code if applicable! **Projects that submit other people's work without proper attribution will be immediately terminated.** + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 0.83 FTE +- **Total Costs:** 25,000 USD + +### Milestone 1 Plutonication Server (Python: Flask) + +- **Estimated Duration:** 1 month +- **FTE:** 0.33 +- **Costs:** 5,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | We will provide both **in code documentation for individual methods**. We will also provide a tutorial on how to run the Plutonication Server locally and in cloud. | +| **0c.** | Testing and Testing Guide | ~~All of the functions will be end-to-end tested with a sample dApp written in typescript (with Plutonication and Polkadot.js api) and a sample Wallet (PlutoWallet)~~ Unit tests for all of the functions | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone and for running the server in production. | +| 1. | PlutonicationServerFlask | A Python server with Flask and Flask-SocketIO used for establishing a stable websocket connection between the dApp and Wallet. Use of server is crucial for reliable establishing of connection. | +| 1a. | create_room | dApp creates room | +| 1b. | pubkey | Sends an account address (SS58 encoded) from wallet to dApp | +| 1c. | sign_payload | dApp requests an extrinsic payload signature | +| 1d. | sign_raw | dApp requests a raw message signature | +| 1e. | payload_signature | wallet provides an extrinsic payload signature | +| 1f. | raw_signature | wallet provides a raw message signature | +| 2. | database requirements | none | + +### Milestone 2 Plutonication Typescript version + +- **Estimated Duration:** 1 month +- **FTE:** 0.5 +- **Costs:** 7500 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | We will provide both **in code documentation for individual methods** and a **tutorial** explaining how to integrate Plutonication into a javascript/typescript dApp. | +| **0c.** | Testing and Testing Guide | All of the functions will be end-to-end tested with a sample dApp written in typescript (with Plutonication and Polkadot.js api) and a sample Wallet (PlutoWallet) | +| **0d.** | Docker | We will provide a Dockerfile for a sample dApp that can be used to test all the functionality delivered with this milestone. | +| 1. | PlutonicationDAppClient | This would be a series of methods tailored for use with dApps. We will make sure that it is compatible with polkadot.js api | +| 1a. | Initialize(AccessCredentials ac) -> void | Method used for initializing the PlutonicationDAppClient | +| 1b. | ReceiveAddress() -> Address | Handles the receiving of SS58 encoded address | +| 1c. | SendPayloadAsync(Payload payload) -> void | Method used for requesting an extrinsic payload sign | +| 1d. | SendRawAsync(Bytes rawMessage) -> void | Method used for requesting a raw message sign | +| 2. | PlutonicationWalletClient | This would be a series of methods tailored for use with wallets. | +| 2a. | SendAddress(Address address) -> void | Sends the SS58 encoded address of the account in the wallet | +| 2b. | SendSignedPayloadAsync(Payload signedPayload) -> void | Method used for sending a signed extrinsic payload back to the dApp. The signed extrinsic payload will then be added to the extrinsic and submitted to chain. | +| 2c. | SendSignedRawAsync(bytes signedRaw) -> void | Method used for sending a signed raw message back to the dApp. | +| 3. | QR code pop-up | We will provide a function that would embed an HTML qr code popup into a dApp. The QR code is used for establishing a connection. | +| 4. | NPM package | We will provide an NPM package, which is commonly used it javascript/typescript development. | +| 5. | Sample dApp | We will make a sample typescript console dApp (with Plutonication and Polkadot.js api) published to a public github repo. | + +### Milestone 3 Plutonication C# version + +- **Estimated duration:** 1 month +- **FTE:** 0.5 +- **Costs:** 7500 USD + +> :exclamation: **The default deliverables 0a-0d below are mandatory for all milestones**, and deliverable 0e at least for the last one. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | We will provide both **in code documentation for individual methods** and a **tutorial** explaining how to integrate Plutonication into a c# dApp. | +| **0c.** | Testing and Testing Guide | All of the functions will be end-to-end tested with a sample dApp written in c# (with Plutonication and Substrate.NetApi) and a sample Wallet (PlutoWallet) | +| **0d.** | Docker | We will provide a Dockerfile for a sample dApp that can be used to test all the functionality delivered with this milestone. | +| 1. | PlutonicationDAppClient | This would be a series of methods tailored for use with dApps. We will make sure that it is compatible with Substrate.NetApi | +| 1a. | Initialize(AccessCredentials ac) -> void | Method used for initializing the PlutonicationDAppClient | +| 1b. | ReceiveAddress() -> Address | Handles the receiving of SS58 encoded address | +| 1c. | SendPayloadAsync(Payload payload) -> void | Method used for requesting an extrinsic payload sign | +| 1d. | SendRawAsync(bytes rawMessage) -> void | Method used for requesting a raw message sign | +| 2. | PlutonicationWalletClient | This would be a series of methods tailored for use with wallets. | +| 2a. | SendAddress() -> Address | Sends the SS58 encoded address of the account in the wallet | +| 2b. | SendSignedPayloadAsync(Payload payload) -> void | Method used for sending a signed extrinsic payload back to the dApp. The signed extrinsic payload will then be added to the extrinsic and submitted to chain. | +| 2c. | SendSignedRawAsync(bytes signedRaw) -> void | Method used for sending a signed raw message back to the dApp. | +| 3. | NuGet package | We will provide a NuGet package, which is commonly used it c# development. It is comparable to NPM packages in Javascript world. | +| 4. | Sample dApp | We will make a sample C# console dApp (with Plutonication and Substrate.NetApi) published to a public github repo. | +| 5. | Testing moved from milestone 1 | All of the functions will be end-to-end tested with a sample dApp written in typescript (with Plutonication and Polkadot.js api) and a sample Wallet (PlutoWallet) | + +### Milestone 4 Plutonication extension + +- **Estimated Duration:** 1 month +- **FTE:** 0.33 +- **Costs:** 5,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | MIT | +| **0b.** | Documentation | We will provide **inline documentation of the code**. | +| **0c.** | Testing and Testing Guide | All of the functions will be end-to-end tested with a sample dApp (https://polkadot.js.org/apps/) and a sample Wallet (PlutoWallet) | +| **0d.** | Docker | We will not provide a docker file | +| **0e.** | Article | We will publish an article that explains what was done as part of the grant. We will mention how Plutonication is ground-breaking and can be used by anyone. | +| 1. | Plutonication Extension | This is a [polkadot.js extension](https://github.com/polkadot-js/extension) compatible browser extension for Plutonication. | +| 1a. | Inject(..) | Injects the browser extension into the polkadot.js dApp. | +| 1b. | ReceiveAddress(..) | Handles the receiving of SS58 encoded address | +| 1c. | SendPayloadAsync(..) | Method used for requesting an extrinsic payload sign | +| 1d. | ReceiveSignedPayloadAsync(..) | Method used for receiving a signed extrinsic payload data. This signed extrinsic payload will then be added to the extrinsic and submitted to chain. (Done automatically by polkadot.js) | +| 1e. | SendRawAsync(..) | Method used for requesting a raw message sign | +| 1f. | ReceiveSignedRawAsync(..) | Method used for receiving a signed raw message. | +| 2. | Chrome browser extension | Released to Chrome Web Store | + +## Future Plans + +Please include here + +#### how you intend to use, enhance, promote and support your project in the short term, and + +- Once all of these 4 milestones are completed, we will have a solid ground to start integrating Plutonication to other dApps. + +#### the team's long-term plans and intentions in relation to it. + +- Our goal would be to create multiple PRs to already popular dApps to utilise Plutonication. At that point, other wallet companies will have a solid motivation to start integrating Plutonication into their wallets too. + +- Further plans are to combine Plutonication with PlutoWallet custom layouts (find more in PlutoWallet readme: https://github.com/RostislavLitovkin/PlutoWallet) and make onboarding of new users easier. + +- The endgoal would be to become a defaultly used solution for wallet injection. + +## Referral Program (optional) :moneybag: + +You can find more information about the program [here](../README.md#moneybag-referral-program). +- **Referrer:** https://github.com/topmonks +- **Payment Address:** 32NoFbB4x8bZ7YNvjra1DUYcje2B2XQwP3 (BTC) + +- They are a grants alumni. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** - personal recommendation + +Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as: + +#### Work you have already done. + +- https://github.com/cisar2218/Plutonication + +- https://github.com/rostislavLitovkin/plutonicationextension + +- https://github.com/rostislavLitovkin/plutowallet + +#### If there are any other teams who have already contributed (financially) to the project. + +- Nobody has financially supported the project. + +#### Previous grants you may have applied for. + +- None yet. + +#### Why are you focusing on C#? Do you have any relation to Ajuna? + +- I was a c# developer and I still like it to this day. It is probably the best option for game development and in my opinion also the best way to develop mobile applications. +Originally, I wanted to create a mobile dApp with c# frontend, so I did my research and that is how I discovered Ajuna and their [Substrate.NetApi](https://github.com/SubstrateGaming/Substrate.NET.API). +It was an excellent tool to get started and without it, I would have probably gave up and moved on. I still noticed that few of the important features were missing, like these: + - how to securely connect a foreign wallet to a c# dApp. + - how to efficiently query NFT data. + - how to elegantly interact with smart contracts (namely ink! contracts) from c#. + +- So I started addressing them one by one. + - First is Plutonication. + - Second is https://github.com/rostislavlitovkin/uniquery.net (this one is already production ready) + - Third was just brainstormed during PBA. It might be my next project in the future. + +- Regarding Ajuna, I am currently in a very close relationship with them. We discuss a lot of the potential changes and updates made to the Substrate.NetApi. +They are very supportive to me. +Last week, I had a chance to represent Ajuna at the Token2049. So, I was showing off all of the projects that have built on the Substrate.NetApi so far ^^. + +#### Is Plutonication made just for PlutoWallet? + +- Although the name may suggest it, it is not true. The name came from the hackathon, so we figured out a combination of __Pluto + Comunication =__ **Plutonication**. Once we figure out a better name, we will rename it to something more generic. It is totally meant to be used by anyone. We are willing to write a good documentation to make it simple for any developers to use. + +#### Can you share some user numbers or other metrics that show adoption of PlutoWallet? + +- It is in an MVP stage currently, meaning it works quite well, suports all of the important features, can be run on any platform and demonstrates well the idea of customizable layouts. It is on a good track to get released by the end of this year. + +#### Regarding deliverable 4.1, you mean polkadot.js apps, not the extension, correct? + +- I truly meant [polkadot.js extension](https://github.com/polkadot-js/extension) (https://polkadot.js.org/docs/extension/usage/). +This Polkadot.js extension is implemented in polkadot.js.org/apps, which means, that it will also work with polkadot.js apps. + +- Also on the demo video, it already works with polkadot.js.org/apps ^^ + +- What I am trying to say is that it is not just limited to polkadot.js.org/apps, but it can work with any dApp that implements the extension package, which most of the dApps did. + +#### Wallet Connect does have both a [Dapp integration guide](https://docs.walletconnect.com/advanced/multichain/polkadot/dapp-integration-guide) and a [wallet integration guide](https://docs.walletconnect.com/advanced/multichain/polkadot/wallet-integration-guide) for Polkadot. Can you compare to this and what is missing that your solution would provide? + +- WalletConnect for Polkadot is not available for c#. + +- WalletConnect also is not optimised for use with Substrate.NetApi. +This is very important because all of the c# projects currently building on Polkadot ecosystem are using Substrate.NetApi. + +#### You point out that the only way to connect a mobile wallet to a Dapp is through Substrate Connect or Vault, but afaik mobile wallets such as Talisman and Fearless will also let you connect. + +- Substrate Connect / Vault are not very elegant and do not work on any device. The device needs to have access to a camera, which for example consoles do not have. Desktops also do not come with webcam out of the box. Smartwatches also do not have access to camera. + +- Talisman is not a mobile wallet. Sorry, I do not understand the second part of the question. + +#### How do you plan to get developers to use your solution? + +- The developers want to provide secure and easy to use dApps. If they do not have to deal about key management, they can focus on other parts of development. + +- For users, it is very risky to expose the private key. This way, they never expose their private key. The developers should recognize this risk and solve it with this easy to use solution. + +- As far as I know, this is the only solution so far for c# that allows the users to connect their wallet to a Substrate.NetApi dApp. diff --git a/applications/PoCS.md b/applications/PoCS.md new file mode 100644 index 00000000000..0dec616c794 --- /dev/null +++ b/applications/PoCS.md @@ -0,0 +1,213 @@ +# Proof of Contract Stake (Pallet) + +- **Team Name:** Auguth Research Foundation +- **Payment:** FIAT +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +#### One Sentence Summary + +*Forging Secure Public Networks through Staking Smart Contracts* + +#### Brief Description + +Blockchain technology, with the introduction of Ethereum protocol, impacted the ecosystem by introducing the concept of smart contracts. These self-executing contracts have enhanced the functionality and versatility of blockchain networks, opening up a wide array of decentralized applications and use cases. However, despite this pivotal development, there is absence of a consensus mechanism that places smart contracts at its core. Recognizing this critical gap, we present Proof of Contract Stake (PoCS) – The First Developer Centric Consensus. + +PoCS is an innovative staking system that leverages *contract gas history* to select block producers. PoCS integrates elements of both proof-of-work and proof-of-stake. We have introduced a novel concept of **'code-mining'** that incentivizes developers to actively participate in securing the network. By aligning the interests of developers with the network's security, PoCS introduces a dynamic where smart contract creators play a vital role in consensus. In addition, PoCS implements a system of *'stake scoring'*, taking into account factors such as contract age, reputation, and gas utilization. This design not only fortifies the network against collusion type attacks but also ensures a fair and secure environment for all participants. It also addresses a longstanding concern in blockchain consensus models – the 'nothing at stake' attacks . By introducing a non-fungible, non-transferable unit of scarcity for staking, PoCS effectively mitigates this vulnerability, making it a secure and reliable network. In addition, the stake accumulation attack in PoCS is time constraint and patterned which can be easily detected. This escalates costs over time and cannot be expedited with any external resources. + +#### Substrate Integration + +We have chosen Substrate as the foundation for our project's development due to a multitude of compelling reasons. Substrate provides a modular framework for blockchain development platform. By leveraging Substrate's extensive capabilities, we could design our consensus mechanism effectively as it aligns perfectly with our goal of creating a dynamic and adaptable blockchain network. Additionally, our project envisions a future where cross-chain interoperability is a key component. This vision closely resonates with the Polkadot ecosystem, which provides of parachains ecosystem. The parachain ecosystem would help us design a robust implementation and test its interoperability. While this part is still under active research, we foresee our consensus mechanism being well-suited for integration into the broader Polkadot network. Besides, one of the most noteworthy features of Substrate is its native support for WebAssembly (Wasm) built contracts. Considering the research and future extensions, we wanted to develop the consensus on Wasm built contracts. + + +#### Team Interest + +Our interest in this project was sparked by a genuine enthusiasm for blockchain technology. Initially, we began as web3 developers, participating in hackathons and exploring dapp development. However, during one of these hackathons, we encountered notable limitations with the Ethereum Virtual Machine (EVM). Recognizing the need for a more robust solution, our research head, Joby Reuben, who has been researching blockchain for over 4 years, began to delve into various consensus mechanisms. Proof of Contract Stake (PoCS) stemmed out from his previous research and emerged as a promising avenue, and we've been dedicated to refining this concept for the past eight months.As we conducted our research, we identified the need for a WebAssembly (Wasm) environment to effectively implement this mechanism. This led us to the Polkadot ecosystem, which provided a suitable environment for our vision. + +In this landscape of ever-evolving blockchain technology we are poised to reshape the way we approach smart contracts and network security. The grants will help us validate our research and make it more robust with the para chain ecosystem. Thus, through this support, we aim to bring our vision to delivering a practical tool to the community and contributing to the ongoing evolution of blockchain technology. + +### Project Details + +#### Prior work - Research + +Our [PoCS research](https://auguth.org/PRESS/pocs) is documented. We have also included [simulations](https://github.com/auguth/dot_org/tree/ef242d1703ba790d0aff12bf01f1796ce3156d66/assets/pocs/simulation/pocs) on the research document to show how PoCS would behave if Ethereum used PoCS from its genesis block. + +#### Substrate implementation Design + +To implement PoCS on substrate we will be modifying `pallet-contracts` and `pallet-staking` under APACHE 2.0 license. We decided to proceed with this approach since both of these pallets provide the primary required functionalities. In addition to this substrate also provides a elaborate user interface for integrating contracts which will ease out our implementation. Since we will be implementing PoCS as a staking mechanism, we will be using `pallet-staking` with BABE + GRANDPA protocols to modify proof of stake. + +#### Outline of Core functionality + +1. **Fields to be added to Pallet-contracts** +Every newly deployed contract will have three extra storage fields: +* `AccountStakeInfo` (struct) : Struct maintainted for each contract call. It is updated everytime a contract is called. + * `owner` (AccountId) - Owner of the contract + * `delegateTo` (AccountId) - Set by the deployer and for the consensus to know who is the deployer. Only deployer can change this field + * `delegateAt` (Blocknumber) - The field is the current block height when the delegateTo field is updated +* `ContractScarcityInfo` (struct field) - This field will be used to calculate the PoCS stake score. It will be updated anytime a transaction executes which corresponds to that contract. To calculate this we will use + * `reputation` (u64) - a parameter we assign to calculate the reputation of contract which depends on number of times it is called by a user or any other contract + * `recent_blockheight` (BlockNumberFor) - This is introduced to prevent vulnerabilities like DDoS attack + + +2. Staking mechanism:
          +In the context of Substrate, the integration of Babe and Grandpa protocols, alongside the Staking Pallet, complements the PoCS mechanism +* Babe's deterministic block production process aligns with PoCS's commitment to security. Validators with higher reputation and weight history, as determined by the scarcity mapping, are incentivized to actively participate in proposing and validating blocks +* Staking Pallet (Validator Selection): The Staking Pallet integrates with PoCS as validators selected based on their scarcity scores, are entrusted with the responsibility of proposing and validating blocks. This delegation ensures that validators with a proven track record of actively participating in the network are granted the authority to contribute to the consensus process. +* Validator Reward Contract : Validator reward contract will act as a general middleware contract, which could be reusable across different apps/chains built over PoCS. We will build a validator contract which will not be a definitive but a reference contract which can be modified with a custom logic to implement custom reward distribution mechanisms.
          +Outline of some basic functionalities: + 1. Claim Rewards: `claimRewards(address devAddress)` +This function allows a developer to claim their rewards from the Validator Reward. For this it will verify that the caller is the owner of the contract calling the function and ensure that the contract is delegated to the validator. + 2. Calculate Reward Percentage: `calculateRewardPercentage(address contractAddress)`: This function calculates the percentage of rewards that the developer is eligible to claim based on the stake score of the associated contract. + 3. Transfer Rewards: `transferRewards(address devAddress, uint256 rewardAmount)` +: This function transfers the calculated rewards to the developer from the contract. It ensures that the reward amount is valid and available in the contract. + + + Protocol design
          +

          + +

          + +#### What your project is not or will not provide or implement +We have structured our implementation into 3 milestones. In this grant our focus is to develop a first version which would implement pallet-contract to calculate the staking score in simplistic yet efficient way with above mentioned fields. It would handle +* Stake score update when deployer deploys contract +* Stake score update when a user calls contract function or other contracts call the contract function +* Integration with proof of stake in substrate. + +We will continue to research as we implement, not all vulnerabilities might be handled in the very first version with above functionalities. But we will extend it to our future plans or extend the grants after accomplishing the milestones and scope in this proposal. + +### Ecosystem Fit +Our project integrates with the Substrate framework, providing a modular and adaptable foundation for our innovative consensus mechanism. This positions us for potential integration into the broader Polkadot ecosystem, aligning with the vision of cross-chain interoperability through parachains. + + +#### Target Audience +Our primary target audience includes developers within the blockchain space, particularly those focused on Polkadot ink! ecosystem and its developers. Additionally, our project aims to serve the broader community of blockchain enthusiasts seeking to engage with a dynamic and secure consensus mechanism. + +#### What need(s) does your project meet? +Our project addresses the critical need for a consensus mechanism that is developer-centric and tailored to the nuances of smart contract interactions. By incentivizing developers through our Proof of Contract Stake (PoCS) model, we empower them to actively participate in securing the network. This not only enhances network security but also fosters a more collaborative and inclusive blockchain ecosystem. Furthermore, our integration with Substrate and potential linkage to the Polkadot network addresses the need for cross-chain interoperability, opening up a realm of possibilities for decentralized applications and services. + +#### Similar Projects (How it is different) +There are no similar projects in polkadot as well as other blockchains as of now since its proposing a new staking consensus. + +## Team :busts_in_silhouette: + +### Team members + +- Team Leader: Purva Chaudhari +- Team Members : Ajay Joshua (Development) , Joby Reuben (Research) + + +### Contact + +- **Contact Name:** Purva Chaudhari +- **Contact Email:** puc7@pitt.edu + +### Legal Structure + +- **Registered Address:** Bangalore, India - 560016 +- **Registered Legal Entity:** Auguth Research Foundation (CIN : U88900KA2024NPL185633) + +### Team's experience + +- **Purva Chaudhari**: Purva is a Masters Student in Computer Science at University of Pittsburgh. Her coursework is primarily includes on subjects of systems and cryptography. Her thesis is focused in blockchain (decentralised voting system). Prior to it, she has over 2 years of experience in working as a blockchain developer. After completing her bachelers in CS, she worked at Witness Chain for an year as backend blockchain engineer. She has experience in ethereum and solana development. She has also been part of Nethermind and Summer of Bitcoin internships during her bachelors. + +- **Ajay Joshua**: Ajay is a B.Tech graduate in Robotics and Automation. He is well-versed in Solidity with three years of practical experience in developing various web3 projects. During his coursework, Ajay has also worked on various projects, in brain-computer interface, AI-based power management system and distributed node-based space communication. His skills span across blockchain development and cybersecurity. + +- **Joby Reuben**: Joby is a the research lead. He is a dedicated researcher and has been delving deep in blockchains for over 2 years. He has profound understanding of Layer 1 protocols and is passionate to design Layer 1 consensus protocols. Currently he rewriting Ethereum yellow paper for developers as an open contribution. His elaborate research experience and realization of current shortcomings of blockchain has led to the idea of developing first developer incentivising consensus which we look forward to bring into reality. + +Overall we are a team of 6 members, 3 of which are core developers as mentioned above, one assists on basis of task and other 2 handle the non-technical work. + +### Team Code Repos + +- https://github.com/Purva-Chaudhari +- https://github.com/I-Corinthian +- https://github.com/jobyreuben + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/purva-chaudhari-02b12b178/ +- https://www.linkedin.com/in/ajay-joshua-a8a250176/ +- https://www.linkedin.com/in/jobyreuben + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 15 weeks +- **Full-Time Equivalent (FTE):** 3-3.5 +- **Total Costs:** 25,000 USD + +### Milestone 1 - Pallet Contract Update + +- **Estimated duration:** 4 weeks +- **FTE:** 3-3.5 +- **Costs:** 7,000 USD + +| Number | Deliverable | Specification | +|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial to test out the additions | +| 0c. | Testing | Unit testing and testing tutorial | +| 0d. | Docker | Create docker image with updated pallets +| 0e. | Article | Publish article for delineating the additions and workflow of consensus | | +| 1. | Modified Substrate pallet-contracts for PoCS | 1. Try tight coupling of pallet-contracts with pallet-staking for interoperability of the pallets for PoCS consensus.
          2. Add attributes to PoCS pallet and derive them. (eg: Contract scarcity struct, its related mappings etc ) | + +### Milestone 2 — Pallet staking Update + +- **Estimated duration:** 6 weeks +- **FTE:** 3-3.5 +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | Inline documentation of the code and a basic tutorial | +| 0c. | Testing and Testing Guide | Unit testing and testing tutorial| +| 0d. | Docker | Create docker image with updated pallets +| 0e. | Article | Publish article for integrations and additions of new pallet logic| +| 1. | Modify pallet staking for PoCS | Add custom functions and modify some existing functions of pallet staking and pallet contract to implement our attributes and make the pallets interact accordingly | + +### Milestone 3 — Validator Reward Contract, Testing and Documentation + +- **Estimated duration:** 5 weeks +- **FTE:** 3 +- **Costs:** 8,000 USD + +| Number | Deliverable | Specification | +|--------|:-------------------------:|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| +| 0a. | License | MIT license | +| 0b. | Documentation | Inline documentation of the code and a external contract documentation
          We will publish an article/workshop that explains inner workings of PoCS and developer guide to build a PoCS enabled Substrate chain| +| 0c. | Testing and Testing Guide | Unit testing with our validator reward ink! contract | +| 0d. | Docker | Create docker image for entire consensus +| 0e. | Article | Publish lite paper for the consensus | +| 1 | Contract development | Design and implement a validator reward contract. (i.e Co-ordinator contract for rewarding).
          Integrate it with PoCS consensus | +| 2. | Alpha testing and publish paper | Alpha testing of entire consensus. Since it is a new consensus design, we have a separate milestone for analyzation of results over conducting an end to end test of the protocol

          Standalone yellow paper| + + +## Future Plans + +Once completed with this grant milestones, +- Further research on democracy and validator penalty conditions +- Moving towards testnet launch as a sister chain to Polkadot. Since it is first of its kind we will be actively discussing our future plans and research directions with the community. +- We will be focussing more on making PoCS pallets interoperable with current popular Substrate pallets. + +## Referral Program :moneybag: + +- **Referrer:** muddlebee(Anwesh) +- **Payment Address:** 14btqGNtzVpfwW9y5xYrcK7uSfgjGZKxcYAG3fJo6ujHUVS (Polkadot Asset Hub) + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Through recommendation from [Builders Tribe](https://buidlerstribe.com/) to apply for W3F grants + +**If there are any other teams who have already contributed (financially) to the project.** + +No, Self Funded + +**Previous grants you may have applied for** + +No diff --git a/applications/PolkaKey.md b/applications/PolkaKey.md index 9e60398f826..384c0133a77 100644 --- a/applications/PolkaKey.md +++ b/applications/PolkaKey.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# PolkaKey -* **Project:** PolkaKey * **Proposer:** @HiZhaoYun * **Payment Address:** 1NUYKUgjDrzXox7ebeT6xkFN5A64S419Xm diff --git a/applications/PolkaSignIn.md b/applications/PolkaSignIn.md index 4a95782e5e4..0f14601fd54 100644 --- a/applications/PolkaSignIn.md +++ b/applications/PolkaSignIn.md @@ -1,13 +1,13 @@ -# W3F Grant Proposal +# Polka SignIn -* **Project Name:** Polka SignIn -* **Team Name:** Litentry -* **Payment Address:** 0x37a45AdBb275d5d3F8100f4cF16977cd4B0f9Fb7 (USDT) +* **Team Name:** Litentry +* **Payment Address:** 0x37a45AdBb275d5d3F8100f4cF16977cd4B0f9Fb7 (USDT) * **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 +* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/641#issuecomment-1320286386) > ⚠️ *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.* -## Project Overview +## Project Overview ### Overview @@ -32,9 +32,9 @@ to ask the user to sign such a magic string with injected signers and provides i #### Sign in Participants -- **Service providers** are the dApps that have the sign-in requirement. -- **Identity providers** are the injected signers which provide the authentication information of the user who holds the wallet. -- **Resource Owners** are the users who hold the self-custody crypto wallets. +* **Service providers** are the dApps that have the sign-in requirement. +* **Identity providers** are the injected signers which provide the authentication information of the user who holds the wallet. +* **Resource Owners** are the users who hold the self-custody crypto wallets. #### Workflow @@ -51,7 +51,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st ### Implementation -1. Sign-in Request +1. Sign-in Request User want to sign in the dApp by send a simple request with identity chain type, eg: DOT, KSM, ETH etc. @@ -65,7 +65,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -2. Authentication Requirement +2. Authentication Requirement dApp will return the callback info. The callback endpoint is used by Identity provider to send signature data to dApp. @@ -79,7 +79,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -3. Connect to Signer +3. Connect to Signer User sends request to the Identity Provider (Injected Signer like : Polkadot.js Extension, Metamask, Parity Signer ...). @@ -94,7 +94,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -4. Provide Signature +4. Provide Signature The Identity Provider will generate the Signature data. ``` @@ -108,15 +108,15 @@ The workflow works the same with or without OAuth specification. Only the 4th st explains: - - identity-type + * identity-type This field is used to choose the chain type and account. - - public-key + * public-key With the chain account chosen, get the public key of the account. This field will be used by dApp to decrypt the data and verify data consistency. - - account-signed + * account-signed use private key to sign the account. @@ -135,18 +135,17 @@ The workflow works the same with or without OAuth specification. Only the 4th st ``` - - scope - + * scope + scope define the permission needed for the dapp to interact with the account. - - - chanllenge - + + * chanllenge + a text string need to be signed by the private key. - The Identity Provider will send the signature data to the callback endpoint of dApp by step #3. -5. Validation +5. Validation The dApp receives the signature data and do the verification. @@ -160,18 +159,18 @@ The workflow works the same with or without OAuth specification. Only the 4th st ``` Verification Steps: - - use **public-key** to decrypt the data of **account-signed** , this progress should be successful, and get the account address. + * use **public-key** to decrypt the data of **account-signed** , this progress should be successful, and get the account address. **public-key** pairs with **private-key**, this step proves the validity of the private key, and ensure that the data was not tampered with. - - - use **public-key** to generate the address by the specified algorithmic mechanism according to the chain type, and get the account address refer to **public-key** . + * use **public-key** to generate the address by the specified algorithmic mechanism according to the chain type, and get the account address refer to **public-key** . - - verify the two account address , success if they are the same. + * verify the two account address , success if they are the same. - - if failure, it means the public key does not match the account address, it may happen when some malicious users want to impersonate an account. + * if failure, it means the public key does not match the account address, it may happen when some malicious users want to impersonate an account. + + * if success, the dApp should return the response to the Identity Provider with the payload: - - if success, the dApp should return the response to the Identity Provider with the payload: ``` { "verified": true, @@ -179,7 +178,7 @@ The workflow works the same with or without OAuth specification. Only the 4th st } ``` -6. Lookup Identity +6. Lookup Identity The dApp gets the account address . It can retrieve the related information of account from the external service providers , such as ENS, Polkadot/Kusama Identity Registrar, etc. @@ -193,7 +192,7 @@ There is few solution combine the OAuth and self-custody wallet, and no such sol * Hanwen Cheng * Yunjian Bian -* Eric Zhang +* Eric Zhang ### Contact @@ -245,9 +244,8 @@ The hourly pay rate is 50 USD/hour In total is 120 hours, and the total payment will be 6000 USD equivalent USDT. - ## Future Plans -We planned to have a web app for user to manage the access control of the logged platforms, and enable user to curate the profile information in the future. +We planned to have a web app for user to manage the access control of the logged platforms, and enable user to curate the profile information in the future. It would be great to integrate with popular auth solutions in web technology, like passport (node js), next-auth (next.js). diff --git a/applications/Polkadart.md b/applications/Polkadart.md new file mode 100644 index 00000000000..1fb690b8081 --- /dev/null +++ b/applications/Polkadart.md @@ -0,0 +1,245 @@ +# Polkadart + +- **Team Name:** EXPERIO S M LTDA +- **Payment Address:** 167QS6UiF1ZJBkHtngCBoHTSbLm4Rokc2ehfFBEniEGQXB4k (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + +### Overview + +- Polkadart is a Dart library that provides a clean wrapper around all the methods exposed by a Polkadot/Substrate network client and defines all the types exposed by a node. It's an equivalent to [polkadot-api](https://github.com/polkadot-js/api) written in Dart language. + +- Development of a library that allows users to connect to Polkadot/Substrate’s nodes on Flutter platform. + +- The library is already used in a few production environments to decode the storage and extrinsics from Substrate based chains. Today, there are multiple mobile applications built on Flutter and together with React Native it is one of the most popular frameworks to develop multi-platform mobile applications, but until now, there was no possibility to fully interact with Substrate's node. + +### Project Details + +- An overview of the technology stack to be used: +``` +This library will be written purely in Dart technology from scratch. +``` +- Documentation of core components, protocols, architecture, etc. to be deployed: +``` +We will follow Polkadot specifications and, as a license for Polkadart library, we will use Apache 2.0. +``` +- What your project is _not_ or will _not_ provide or implement: +``` +This project will not support legacy metadata protocols, such as metadata v9, v10, v11 and v12. Polkadart will not implement any front-end, since it is going to allow developers to use Dart to connect to the Substrate based network. +``` +- This is a place for you to manage expectations and to clarify any limitations that might not be obvious: +``` +Polkadart is similar to the project "https://github.com/polkadot-js/api" but for Dart, instead of JavaScript. +``` + +### Ecosystem Fit + +- Where and how does your project fit into the ecosystem? +Our project is going to allow developers to use Dart/Flutter to connect to the Substrate-based network. +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? +Our target audience is the mobile app developer's community. +- What need(s) does your project meet? +Polkadart enlarges the range of tools compatible with Polkadot/Substrate, therefore expanding its usability. +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? +Pocket 4 Polkadot-Dart: https://github.com/Pocket4D/Polkadot-Dart#manually-build +Polkaj: https://github.com/emeraldpay/polkaj/blob/master/docs/03-rpc-client.adoc + - If so, how is your project different? +Pocket4 was similar to PolkaDart but it was discontinued for lack of progress and Polkaj is related to Java. + +## Team :busts_in_silhouette: + +### Team members + +- Leonardo Custodio, Blockchain Engineer +- Lohann Ferreira, Lead Blockchain Architect +- Kawaljeet Singh, Flutter Developer +- Gabriel Okura, Flutter Developer +- Bruno Pastre, Senior Flutter Developer + +### Contact + +- **Contact Name:** Leonardo Garcia Custodio +- **Contact Email:** leonardo@custodio.me +- **Website:** https://www.linkedin.com/in/leogcustodio/ + +### Legal Structure + +- **Registered Address:** Rua Capitao Souza Franco, 350 - Ap 22 - Curitiba/PR - Brasil +- **Registered Legal Entity:** Experio S M Ltda + +### Team's experience + +**Leonardo Custodio** + +Leonardo has being working with Polkadot/Substrate stack for the past 27 months. At his current position he makes SDKs that allows game developers to work easily with Substrate based chain. Before that he was the Lead Mobile Developer of Inovatso where he has created multiple applications for the general public like picPics and other entreprise applications using Flutter. + +**Lohann Ferreira** + +Lohann have a deep understanding of Polkadot/Substrate stack amongst other blockchain technologies. Previously worked at [First Foundry](https://www.firstfoundry.co/) as Senior Software Engineer. Founder and lead engineer at [Jurimetric](https://jurimetric.com.br/). Co-founder of [Veever](https://veever.global/), which through the combination of beacons, a web platform, and a mobile app aims to assist people with visual impairment to easily get around and interact with the urban environment. He is focused on solving big problems with simple ambitious solutions. + +**Kawaljeet Singh** + +Before starting to work as a full-time flutter developer at Rankanizer, Kawal was working as a freelance Flutter Developer at Inovatso and on other projects. In his free time, he loves to create open-source tools and plugins in dart to help the Flutter community. He is a blockchain enthusiast and is super dedicated to learning and bringing ideas to life. + +**Gabriel Okura** + +Gabriel is currently working as a mobile and backend developer at Hype Empreendimentos, and for the past year and a half, he has been having experience building apps in Dart with the Flutter framework. Previously worked with mobile game development at Opala Studios. He is excited about the opportunity to work on Rankanizer and to help build the PolkaDart library to increase his experience with blockchain technology. + +**Bruno Pastre** +Bruno is an iOS specialized Software Engineer who has consulted for large tech companies like Coinbase and Wish. +He is fascinated about writing scalable, testable and maintainable code and has been working on that for the past four years. He's a Apple Developer Academy alumni, performing both as a student and a Junior Mentor, There, he had the opportunity to share his knowledge with the next generation of iOS developers and empower them to develop themselfs. + +### Team Code Repos + +- https://github.com/rankanizer +- https://github.com/rankanizer/polkadart +- https://github.com/Lohann +- https://github.com/leonardocustodio +- https://github.com/justkawal +- https://github.com/gabrielokura +- https://github.com/pastre + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/leogcustodio +- https://www.linkedin.com/in/lohannferreira +- https://www.linkedin.com/in/kawal74153 +- https://www.linkedin.com/in/gabriel-motelevicz-okura-aa95491b6 +- https://www.linkedin.com/in/bpastre + +## Development Status :open_book: + +Out of the necessity of having a a library / sdk to use substrate chains in our other planned apps. We will start the development of Polkadart in the Grant's program. The repository that will be used during the development is https://github.com/rankanizer/polkadart. We intend to have it open-source since the beginning and all code will be added through pull-requests. + +We decided to divide this project into three milestones. The first one is building the codec and metadata part. Since without this all data would have to be mocked and tested using third-party tools as everything is encoded in the substrate eco-system. + +After we are able to encode/decode data from primitive types and metadata's of any chain. We are going to proceed with the connectivity part. Where we will implement the interfaces necessary for communicating with the nodes through RPC. + +Finally the last step will be the crypto and utils part where we will have the utilities necessary for signing transactions. After these three milestones are completed we shall have a fully featured library that will enable people in the Dart/Flutter ecosystem to communicate with any substrate based node, sign transactions, encode and decode data. Making it possible for example for people to develop flutter applications for Polkadot using native libraries. + +## Development Roadmap :nut_and_bolt: + +Described above. + +## Overview + +- **Total Estimated Duration:** 15 months. +- **Full-Time Equivalent (FTE):** 4. +- **Total Costs:** 75,000 USD. + +### Milestone 1 — Completed + +- **Estimated duration:** 4 months. +- **FTE:** 4. +- **Costs:** 20,000 USD. + +|Number|Deliverable| Specification | +|:---: | --- | --- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide markdown documentation of how to install and use the API. | +| 0c. | Testing Guide | We will provide sample scripts on how to use it. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test the PoC. | +| 1a. | Scale Codec | First we will port the functionalities of scale codec to Dart. This way developers can decode and encode data from substrate. | +| 1b. | Metadata | Then we will add the metadata parser so it can decode/encode the data by looking at the metadata. Important to note that we do not inteed to support legacy versions | +| 1c. | Tests | Unit tests for deliverables above | + + +### Milestone 2 — Completed + +- **Estimated duration:** 1 month. +- **FTE:** 4. +- **Costs:** 15,000 USD. + +|Number|Deliverable| Specification | +|:---: | --- | --- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide markdown documentation of how to install and use the API. | +| 0c. | Testing Guide | We will provide sample scripts on how to use it. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test the PoC. | +| 2a. | RPC | We will create the interfaces to use and connect to the node through RPC. | +| 2b. | Websockets | We will add websockets support to the above. | +| 2e. | Tests | Unit tests for deliverables above | + +### Milestone 3 — Completed + +- **Estimated duration:** 6 months +- **FTE:** 2. +- **Costs:** 20,000 USD. + +|Number|Deliverable| Specification | +|:---: | --- | --- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide markdown documentation of how to install and use the API. | +| 0c. | Testing Guide | We will provide sample scripts on how to use it. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test the PoC. | +| 0e. | Article/Workshop | We will publish an example flutter project using the library to explain what was done and how to use it. | +| 3a. | Substrate Uri | Implement Substrate's standard derivation format that applies to seeds and mnemonics. | +| 3b. | Encrypt/Decrypt | Use Substrate's Bip39 password to encrypt/decrypt seeds and mnemonics. | +| 3c. | Ed25519 | Support Ed25519 signatures and key derivation | +| 3e. | Sign & Verify | Sign and verify messages using ed25519 keypairs | +| 3f. | Substrate Signed Extensions | Support substrate's signed extensions | +| 3g. | AssetHub Signed Extensions | Support AssetHub's signed extensions | +| 3h. | Transaction Subscriptions | Support transaction subscription | +| 3i. | Event Subscriptions | Support runtime event subscription | +| 3j. | Keyring | Create a package that manage a set of keys in a consistent environment | +| 3k. | Crypto | Utilities needed for signing, hash and encode/decode messages | +| 3l. | Tests | Unit tests for deliverables above | +| 3m. | Pub.dev | Publish to pub.dev | + +### Milestone 4 — Completed + +- **Estimated duration:** 4 months +- **FTE:** 2. +- **Costs:** 20,000 USD + +|Number|Deliverable| Specification | +|:---: | --- | --- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide markdown documentation of how to install and use the API. | +| 0c. | Testing Guide | We will provide sample scripts on how to use it. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test the PoC. | +| 4a¹. | Research sr25519 | More research needs to be done to decide what is the best path forward to support sr25519, one of the following might be done | +| 4a². | Rewrite Schnorrkel in Dart | Rewrite [schnorrkel](https://github.com/w3f/schnorrkel) in pure dart | +| 4a³. | Use rust schnorrkel | Make dart wrappers to use rust bindings to use schnorrkel lib | +| 4b. | Ecdsa/Secp256k1 | Support Ecdsa/Secp256k1 signatures and key derivation | +| 4c. | Sign & Verify | Sign and verify messages using sr25519 and ecdsa keypairs | +| 4e. | Custom RPC | Support custom RPC methods | +| 4f. | Custom Signed Extensions | Support custom signed extensions | +| 4g. | Multisig Account | Implement's Substrate's Multisig Account | +| 4h. | Tests | Unit tests for deliverables above | +| 4i. | Pub.dev | Publish to pub.dev | + +## Future Plans + +Until now we are bootstrapping, but we intend to continue to support the project with W3F Grant's help. + +Our intention is to make the library available to whoever has an interest in using it. We need it to build Rankanizer, the next-generation app for enabling multiple-choice anonymous voting. Rankanizer will be a transparent and decentralized voting software built on blockchain technology. + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Lohann was informed about the Grants Program by personal recommendation. + +💾 **Work you have already done.** + +**Lohann's previous work:** \ +[Forte](https://forte.io) \ +[Rally](https://rally.io) \ +[Efinity](https://efinity.io) \ +[Collectiba](https://www.youtube.com/watch?v=QftJoDz2JXU) + +**Binder's previous work:** \ +[Software project: Cluster](https://clusterforchange.com/) - Social Impact Platform. Project Manager, Software Architect. \ +[Award: Apple Distinguished Educator 2019](https://www.apple.com/education/k12/apple-distinguished-educator/) \ +[PHD Thesis](https://pergamum-biblioteca.pucpr.br/acervo/338937) \ +[StackOverflow: 12.000+ points (top 3% overall)](https://stackoverflow.com/users/86154/fabio-vinicius-binder) \ +[Personal Researcher Profile on Scopus](https://www.scopus.com/authid/detail.uri?authorId=56730458300) + +**Kawal's previous work:** \ +[AnimatedText](https://github.com/justkawal/animated_text) \ +[Protect](https://github.com/justkawal/protect) \ +[Tenor](https://github.com/justkawal/tenor) \ +[Excel](https://github.com/justkawal/excel) diff --git a/applications/Polkadot-Dart.md b/applications/Polkadot-Dart.md index add788510b8..46a8deddefa 100644 --- a/applications/Polkadot-Dart.md +++ b/applications/Polkadot-Dart.md @@ -1,20 +1,16 @@ -Open Grant Proposal of Polkadot-Dart - -* **Project:** Polkadot-Dart +# Polkadot-Dart * **Proposer:** Michael So * **Payment Address:** 3PbhNyWhiSTwb58fc5uYhg2mV2vJ34KwAJ -* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/125#issuecomment-946479942) - - +* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/125#issuecomment-946479942) -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview -Dart has advantages in native development. +Dart has advantages in native development. Dart is a computer programming language developed by Google, which is used in the development of web, server, mobile apps and the IoT. Dart is an object-oriented, class-defined, single-inheritance language. Dart is a general programming language developed by Google, which was later recognized as a standard by ECMA (ECMA-408). It is used to build web, server, desktop and mobile applications. Its syntax is similar to C language and can be translated into JavaScript, interfaces, mixins, abstract classes, reified generics, optional typing and sound type system . @@ -28,9 +24,9 @@ Similarly, we also found that there is currently no Polkadot SDK suitable for th Similar to [polkaj](https://github.com/emeraldpay/polkaj) (Java version), we will develop the Dart version and name it `Polkadot-Dart`. +### Project Details -### Project Details -To complete the porting, we follow the project structure of `Polkadot-JS`. +To complete the porting, we follow the project structure of `Polkadot-JS`. There are some differences between `Dart` and `Javascript`, and the project needs to be compatible. For example, The "wasm" compiled by Rust-lang is used in `Polkadot-JS` . As for dart, we use `dart:ffi` for communication. All Rust-native libraries will be compiled to `.so` for Linux/Android system, `.a` or `.framework` for iOS/MacOS, and `.dll` for Windows. @@ -62,23 +58,21 @@ Therefore, we defined Dart project like `Polkadot-JS` . | `@polkadot/type-known` | * not needed | | `@polkadot/types` | types | - #### Technology Stacks Dart/Flutter, Rust +### Ecosystem Fit -### Ecosystem Fit +Similar projects: -Similar projects: * [Web3dart](https://github.com/simolus3/web3dart) * [polkaj](https://github.com/emeraldpay/polkaj) * [Dart-scale-codec](https://github.com/nbltrust/dart-scale-codec) -* [Substrate-sign-flutter](https://github.com/hanwencheng/substrate_sign_flutter) +* [Substrate-sign-flutter](https://github.com/hanwencheng/substrate_sign_flutter) We have created `Polkadot-Dart`, which, combined with Flutter framework, can greatly reduce the barrier to participation for cross-platform developers, as well as reduce the complexity of cross-platform application development and maintenance. In addition, the cross-platform experience of Polkadot-Dart's users is also improved. - ## Team :busts_in_silhouette: ### Team members @@ -86,12 +80,12 @@ We have created `Polkadot-Dart`, which, combined with Flutter framework, can gre * Michael So * Zhongdan Wei -### Team Website +### Team Website * https://pocket4d.io (In progress) * https://firestack.one -### Legal Structure +### Legal Structure SHANGHAI NIEPAN INFORMATION TECHNOLOGY CO., LTD., a startup company focusing on blockchain development in China. @@ -100,7 +94,6 @@ SHANGHAI NIEPAN INFORMATION TECHNOLOGY CO., LTD., a startup company focusing on * Michael So, founder of FireStack, Serial entrepreneur. He devoted to blockchain for many years, leading token investment, wallet, blockchain game platform and other projects, and has accumulated rich experience in blockchain theories and practice. * Zhongdan Wei, front-end architect, proficient in Flutter. As a leading member in Hellobike, he led the team to develop the Mobike Applications and makes it easy and fast to add flutter to existing mobile applications. - ### Team Code Repos * https://github.com/Pocket4D/p4d-rust-binding (Will be renamed after proposal is accepted) @@ -109,7 +102,7 @@ SHANGHAI NIEPAN INFORMATION TECHNOLOGY CO., LTD., a startup company focusing on None. -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: ### Overview @@ -173,7 +166,6 @@ None. | 1 | documentations | Documentations for all packages | | 2 | pub.dev | Publish to pub.dev for v1.0.0 | - ### Community Engagement We are buiding our community on https://www.yuque.com/?language=en-us and newsletters will be regularly updated soon. @@ -192,22 +184,25 @@ We are buiding our community on https://www.yuque.com/?language=en-us and newsle | ☐ | 5 | network | Porting and implements `@polkadot/network` | | ☑ | 6 | tests | Unit tests for deliverables above | - ## Future Plans ### Maintainance + 1. Keep following the upgrade of `Polkadot-JS` and `Substrate`, and supporting latest upgrades as soon as possible. 2. Seperate the rust/dart binding libs and other implementations to serveral packages, the native binding libs should be minimize and stable for long term, just like `@polkadot/wasm` does. And we should be focusing on upgrading the features. ### Products and ecosystems -1. We have a plan of making a wallet app, using `Polkadot-Dart` as its main dependency, which has been communicated with many parachains, to prepare for linking into `Parachains` and lowering the threshold for users to use. + +1. We have a plan of making a wallet app, using `Polkadot-Dart` as its main dependency, which has been communicated with many parachains, to prepare for linking into `Parachains` and lowering the threshold for users to use. 2. We also have another substrate-based project called [Pocket4D](https://github.com/Pocket4D/), combining `Polkadot-Dart` and other components, we plan to build a new decentralized network. And `Polkadot-Dart` will be one of our client side core dependency. 3. The main purpose of this lib is to co-operate with ecosystem partners, especially `Parachains`, we need to build and test with them and fit their needs. - ## Additional Information ➕ + ### Are there are any teams who have already contributed (financially) to the project? + No. ### Have you applied for other grants so far? + [Pocket4D](https://github.com/w3f/General-Grants-Program/pull/340) diff --git a/applications/Polkadot-Protocol-Conformance-Tests.md b/applications/Polkadot-Protocol-Conformance-Tests.md new file mode 100644 index 00000000000..ed9e978e725 --- /dev/null +++ b/applications/Polkadot-Protocol-Conformance-Tests.md @@ -0,0 +1,154 @@ +# Polkadot Protocol Conformance Tests Research Proposal + +- **Team Name:** [LimeChain](https://github.com/LimeChain) +- **Payment Address:** 14dut6zGgdVmKijePZzrQAy2gZ6FmMDmzzp7VqjzPV9E4ujR (USDT on Polkadot AssetHub) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + +This research proposal is in response to the currently open [Polkadot Protocol Conformance Tests RFP](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/Open/polkadot-protocol_conformance_tests.md). + +### Overview + +Polkadot has made substantial progress over the last few years in terms of client diversification. Currently, there are 4 existing host implementations with varying features and protocol support: [Polkadot](https://github.com/paritytech/polkadot) by Parity, [Kagome](https://github.com/soramitsu/kagome) by Soramitsu, [Gossamer](https://github.com/ChainSafe/gossamer/) by ChainSafe, and [Fruzhin](https://github.com/limechain/fruzhin) by LimeChain. Having a healthy client diversity is beneficial to every blockchain protocol as it becomes more decentralised and less bug-prone. Neglecting these aspects has resulted in halting block production for some blockchain protocols in the past. + +The nature of software is such that it's never perfect, and bugs happen. Therefore, multiple host implementations come with a higher probability of implementation-specific issues. It's important for a blockchain protocol that takes great pride in its decentralisation, such as Polkadot, to have a protocol compliance testing suite that verifies the behaviour of each implementation. The more comprehensive the testing suite is, the stronger security guarantees the protocol can provide. + +The goal of this project is to prepare for the redesign of the existing [conformance tests repository](https://github.com/w3f/polkadot-tests). Our team envisions the redesigned testing suite to be easily extensible and flexible, welcoming contributors to enhance it with their domain-specific knowledge. Concerns have been raised regarding the "adapter" approach that the existing testing suite has taken and that the chosen language ([Julia](https://julialang.org/)) is out of sync with the one for Polkadot ([Rust](https://www.rust-lang.org/)). This proposal aims to lay the groundwork for resolving these issues by delving deep into the biggest obstacle that stands in the way: finding the correct level of abstraction and tooling that will be the cornerstone for every kind of test scenario. + +### Project Details + +### A host-agnostic approach + +A conformance testing suite should be host-agnostic, meaning that, for the most part, the tests shouldn't be concerned with the specific Host implementation against which they are being executed. The Host exposes several interfaces that enable conformance testing; however, it’s a complex piece of engineering, and there will always be protocols and functionalities without an exposed interface. Moreover, there are integration tests that can't be conducted using an API. These scenarios are as important as the previous ones because the Host can't function properly if the modules don't work seamlessly with one another. + +### Host API + +The Host API consists of a set of functions that the Host exposes to the Runtime. These functions are used to access external resources for various purposes, including storage access, manipulation, memory allocation, and more. If a method within the API contains a bug, it has the potential to push the Host into an incorrect state transition. Such a scenario could lead to undefined consequences, particularly if a significant number of nodes experience the same issue. + +### SCALE + +Substrate employs a lightweight and efficient encoding and decoding mechanism to optimise the transmission and reception of data across the network. This protocol, known as the SCALE codec, plays a vital role in serialising and deserialising data. It serves as a critical component for data transfer across the peer network and facilitates communication between the Runtime and the Host. Consequently, the presence of comprehensive tests for SCALE encoding and decoding holds immense significance in ensuring the proper functionality of the Host. + +### State Trie + +The state trie is another crucial part of the Host. A radix-16 state is the data structure that Substrate uses to store the state of the blockchain. Without thoroughly tested state trie functionalities, the Host may transition to an incorrect state and get slashed if it's a block producer. + +### BABE & GRANDPA + +[BABE](https://spec.polkadot.network/sect-block-production) & [GRANDPA](https://github.com/paritytech/finality-grandpa) are the bread and butter of the consensus-reaching module for Polkadot. However, finding the right tools and approach to test the block production and finalisation protocols independently of the Host’s environment is a challenge that is yet to be overcome by any team. + +### Zombienet + +[Zombienet](https://github.com/paritytech/zombienet) aims to be a testing framework for Substrate-based blockchains, providing a CLI tool that allows users to spawn and test ephemeral networks. The assertions used in the tests can include on-chain storage, metrics, logs, and custom JavaScript scripts that interact with the chain + +Our team has successfully utilised Zombienet to run PVF conformance tests as part of another W3F grant. This is the reason why we believe that Zombienet has the potential to be the go-to framework for running conformance tests on the Hosts. The research is going to focus on Zombienet, as well as on the new [Zombienet SDK](https://github.com/paritytech/zombienet-sdk). + +### Research Scope + +The main focus of the research will be on investigating each of the aforementioned protocols and functionalities and how they can be tested in a host-agnostic manner. Based on our preliminary research and the work we've conducted on the PVF conformance testing suite, our team believes that Zombienet can serve as the foundation for the testing suite. The team will examine whether Hosts and Zombienet have the required feature set to support such testing scenarios. If this is not achievable, the team will document the missing components so that they can be identified and potentially contributed in a future proposal. + +Our team acknowledges that, for certain Hosts, having the Host API, SCALE, and State Trie as standalone artifacts could be beneficial for Host developers during the early phases of their implementation. However, this proposal primarily focuses on adopting a host-agnostic approach for Hosts that are already functioning with the already existing tests. Depending on the research outcomes, our team may subsequently introduce a new proposal involving the redesign of the conformance repository. In this redesign, the tests would be separated into a standalone artifact and transformed into Zombienet tests. + +### Ecosystem Fit + +By delivering a research document containing insightful information about the necessary steps to commence the redesign of the Polkadot Conformance Testing repository, we aim for it to serve as a catalyst to initiate the development process + +Initially, the Polkadot Conformance Testing repository will be situated in close proximity to the realm of Polkadot Hosts. Its primary target audience will be Host developers seeking comprehensive testing for their Hosts. Other individuals who might find this project valuable include experts from the Polkadot specification team, who can contribute their expertise in specific scenarios. + +## Team 👥 + +### Team members + +- Viktor Todorov +- Maksim Dimitrov +- Kristiyan Veselinov + +### Contact + +- **Contact Name:** Kristiyan Veselinov +- **Contact Email:** kris@limechain.tech +- **Website:** [https://limechain.tech](https://limechain.tech/) + +### Legal Structure + +- **Registered Address:** Bulgaria, Dragan Tsankov 23A, 1113, Sofia, Bulgaria +- **Registered Legal Entity:** LimeLabs Ltd. + +### Team's experience + +At LimeChain, we possess considerable expertise in developing various tools, including [Gosemble, a framework for building Substrate compatible Runtimes in Go](https://github.com/LimeChain/gosemble), [Fruzhin, a Host implementation in Java](https://github.com/limechain/fruzhin), [a framework for runtimes in AssemblyScript](https://github.com/LimeChain/subsembly), a framework for runtimes in AssemblyScript. On top of that, we’re working on a [Parachain Validation Conformance Testing suite](https://polkadot.polkassembly.io/motion/389), have substantial experience in Rust/WebAssembly developer tooling from [Matchstick](https://github.com/limeChain/matchstick/) and actively contribute to infrastructure projects in Cosmos and Hedera Hashgraph. + +### Team Code Repos + +- [https://github.com/LimeChain](https://github.com/LimeChain) + +Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. + +- [https://github.com/vikinatora](https://github.com/vikinatora) + +### Team LinkedIn Profiles (if available) + +- [https://www.linkedin.com/in/viktor-todorov-8a7434122/](https://www.linkedin.com/in/viktor-todorov-8a7434122/) +- [https://www.linkedin.com/in/chris-veselinov/](https://www.linkedin.com/in/chris-veselinov/) + +## Development Status :open_book: + +No actual development has been made for this RFP. However, the team has spent a significant amount of time delving into the Host’s specification as part of the Java Host implementation we're currently working on. Additionally, our work on the PVF conformance testing suite has enhanced our understanding of how to address challenging-to-test sections of the code. + +## Development Roadmap :nut_and_bolt: + +The primary framework under consideration for this research will be Zombienet, as it already provides the groundwork for these types of tests. Each of the steps outlined below will be dedicated to investigating the creation of Zombienet tests for the specified functionalities. The team will also document in the research report the development steps required to enable testing of the specified functionality using Zombienet. + +Outlined below are the testing scenarios for each Host module that will be the focus of the research: + +1. Host API + 1. Trie +2. SCALE + 1. SCALE encoding + 2. SCALE decoding +3. State Trie + 1. Trie encoding + 2. Trie decoding +4. BABE + 1. Block import + 2. Block validation +5. GRANDPA + 1. Block import + 2. Block validation + +### Overview + +- **Total Estimated Duration:** 8 working weeks +- **Full-Time Equivalent (FTE):** 2 +- **Total Costs:** $49280 + +### Milestone 1 — Polkadot Conformance Testing Suite Research + +- **Estimated duration:** 8 working weeks +- **FTE:** 2 +- **Costs:** $49280 + +| Number | Deliverable | Specification | +| --- | --- | --- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide inline documentation, as well as README file with how the suite can be executed. Additional information will be provided on how to contribute. | +| 0c. | Testing and Testing Guide | Documentation will be provided that showcases how the testing suite can be executed for different scenarios and hosts. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an article that explains what was done/achieved as part of the grant. | +| 1. | Host API Research | Research the feasibility of using Zombienet as the framework for executing Host API tests. | +| 2. | SCALE Research | Research the feasibility of using Zombienet for conducting SCALE encoding and decoding tests. | +| 3. | State Trie Research | Research the feasibility of using Zombienet for conducting State Trie encoding, decoding and generation tests. | +| 4. | BABE Research | Research the feasibility of using Zombienet for conducting BABE tests. | +| 5. | GRANDPA Research | Research the feasibility of using Zombienet as the framework for conducting GRANDPA tests. | +| 6. | Research Findings | A research document will be delivered documenting the team’s findings, as well as outline a high-level path forward for the conformance testing suite. | + +## Future Plans + +Based on the research findings, our team could formulate a proposal for implementing these tests and restructuring the conformance testing suite with the new approach, and/or contributing the necessary features that would enable Zombienet to be utilised for these purposes. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +At LimeChain, we have been contributors to the Polkadot ecosystem for the last 3+ years as we believe in a multi-chain future, based on interoperability and decentralisation. Principles that are built into the core of the Polkadot network. We possess considerable expertise in developing various tools, including [Gosemble, a framework for building Substrate compatible Runtimes in Go](https://github.com/LimeChain/gosemble), [a framework for runtimes in AssemblyScript](https://github.com/LimeChain/subsembly),, and [Parachain Validation Conformance Testing](https://polkadot.polkassembly.io/motion/389). Additionally, we have substantial experience in Rust/WebAssembly developer tooling from [Matchstick](https://github.com/limeChain/matchstick/) and have actively contributed to infrastructure projects in Cosmos, Near, Filecoin, Ledger and Hedera Hashgraph. diff --git a/applications/PolkadotSnap.md b/applications/PolkadotSnap.md new file mode 100644 index 00000000000..b13d98397ea --- /dev/null +++ b/applications/PolkadotSnap.md @@ -0,0 +1,159 @@ +# Polkadot Snap Made by Keystone Wallet Team + +* **Team Name:** Keystone Wallet Team +* **Proposer:** @aaronisme +* **Payment Address:** 3KL2HNETiLbLVbnGfpGZ6ZkyyaWUL6bfpt（BTC） +* **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +* **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1166#issuecomment-1567918173) + +## Project Overview :page_facing_up: + +Keystone (Previously Cobo Vault) is the official partner of MetaMask and Solflare wallet, and we are also the ONLY hardware wallet compatible with MetaMask mobile (demo video). +Apart from our hardware wallet business unit, another major unit of ours is MetaMask Snaps Development. We are the first verified Snap developer of MetaMask building BitcoinSnap. +Keystone is dedicated to developing a so-called “Polkadot Snap” to help your team open up one of the biggest WEB3.O entrances - MetaMask, where users could continue exploring the Polkadot ecosystem with their familiar MetaMask Wallet. +As always, we appreciate Polkadot's vision and try to scale with the team, by building the win-win Polkadot Snap, we believe it benefits both of us in a long term perspective. + + +### Project Details + +Polkadot Snap is a “Snap Application” running on MetaMask. Polkadot Snap will act in two ways for users. Firstly it will be the wallet adapter for Dapp developers. With it, the Dapp can interact with MetaMask for Polkadot. Secondly, The Polkadot Snap will be the wallet for Polkadot. It will provide functionality like transferring assets, staking tokens, etc. + +We will use React, Mobx, and Typescript for building this application. Considering Polkadot Snap is not completed yet, we put some samples of our BTCSnap for your reference. +- Alpha version of BTCSnap：https://btc.justsnap.io/ +- Demo: https://www.youtube.com/watch?v=9B-nnnaFq0o +- BTCSnap Repo: https://github.com/KeystoneHQ/btcsnap + + +### 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? + - First Polkadot Snap: Keystone aims to be the first Polkadot Snap developer and build the first open-source Polkadot Snap for the Polkadot ecosystem. +- User acquisition: As promised, BitcoinSnap will be officially recommended by MetaMask and we will drive traffic to Polkadot Snap through our BitcoinSnap so tens of millions of MetaMask users will get easier access to the Polkadot ecosystem. +- Lower the threshold: No more other wallets are needed so less friction for users when they start exploring Polkadot. + +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? +- Our target audience will be 1) all the MetaMask users who want to explore the Polkadot ecosystem in a more efficient way. 2) all the Polkadot users who get used to the MetaMask wallet. 3) all the projects on Polkadot chain want to get users from MetaMask + +- What need(s) does your project meet? +- Polkadot Snap will meet the needs: 1) Sign in one place for different blockchain transactions. 2) Lower barriers to enter the Polkadot ecosystem. 3) Users acquisition needs from different projects no matter whether they are deployed on Polkadot, Ethereum or other EVM chains. + + +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? +- No. + + +## Team :busts_in_silhouette: + +### Team members + +- Name of team leader: Lixin Liu, CEO +- Names of team members: +Aaron Chen, CTO +Bobby Wang, Head of BD +Truda Hamzik, Head of Communications +Jimmy cheung, Head of Design +Shaun Guo, Project manager +Bill Lee, Product manager + +### Contact + +- **Contact Name:** Bobby Wang +- **Contact Email:** bobby@keyst.one +- **Website:** N/A + +### Legal Structure + +- **Registered Address:** 19H MAXGRAND PLAZA, NO.3 TAI YAU STREET, SAN PO KONG, KOWLOON, HONGKONG. +- **Registered Legal Entity:** Yanssie HK Limited + +### Team's experience + + +Keystone (previously Cobo Vault), the official partners of MetaMask and Solflare wallet, and we are also the ONLY hardware wallet compatible with MetaMask mobile (demo video). +We have our mature flagship product which is Keystone hardware wallet. +Apart from that, another major business unit is MetaMask Snaps development. We are the first verified Snap developer of MetaMask building BitcoinSnap (https://www.youtube.com/watch?v=oxkmissJbiM). This BitcoinSnap will be recommended by MetaMask when Snaps officially launch in a few months. +Keystone is also the co-author of BIP-129 and EIP-4527, +Keystone (previously as Cobo Vault) has applied for a grant, the project name was Cobo Vault, and the legal entity was Shanghai Nanqian Technology Co., Ltd. + + + +### Team Code Repos +https://github.com/KeystoneHQ/btcsnap +https://github.com/KeystoneHQ/Keystone-cold-app + +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/orgs/KeystoneHQ/people/aaronisme +https://github.com/orgs/KeystoneHQ/people/zhaomengru2015 +https://github.com/orgs/KeystoneHQ/people/LiYanLance +https://github.com/orgs/KeystoneHQ/people/soralit + +### Team LinkedIn Profiles (if available) + +N/A + +## Development Roadmap :nut_and_bolt: + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 4 FTE +- **Total Costs:** 30k USD + +### Milestone 1: + +- **Total Estimated Duration:** 1 months +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 10k USD + +In Milestone one, we will develope the wallet adaptor based on MetaMask Snap. We will create the wallet adaptor for Polkadot. The are at least these things should be covered: +Building the snap application +Provider and js sdk which wrap the snap application which provide injected object for the Dapp developer. +Writing the documentation for the Dapp developer. + +After this milestone, we will open-source all the implementation code and examples. +Bascily, every dapp can use this wallet adapter to interact with MetaMask + +To hit this milestone, one month full-time work is needed for our secure element firmware engineer (Sora - Frontend Engineer ), 0.5 month full-time work is needed for our QA engineer (Xia MengYun - QA Engineer). +Grants are 10k 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 dapp developer can use this library to use the MetaMask flask as the wallet for the user. | +| 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. | Demo | We will publish an demo to show how to use this library for the dapp developers | +| 0e. | Article | We will publish an article that explains how to use this wallet adaptor and MetaMask Flask to interact with Polkadot dapps. | +| 1. | js sdk | Building the snap application Provider and js sdk which wraps the snap application and provides an injected object for the Dapp developer. Writing the documentation for the Dapp developer. | + +### Milestone 2: + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 4 FTE +- **Total Costs:** 20k USD + +In milestone two, we will develop the Polkadot Wallet. It will also use our snap and provide functionality like transferring assets like DOT/KSM. Staking etc. + +Here is the feature list for this Polkadot Wallet. +1. Users can use this wallet to manage their assets like DOT/KSM. +2. Users can use this wallet to track their transaction history. +3. Users can use this wallet to manage their NFTs. +4. Users can use this wallet to contribute the Crowdloans +5. Users can use this wallet to stake their DOT/KSMs. +6. This wallet will support both Polkadot and kusama chains. + +The Polkadot wallet we will build which will rely on Polkadot snap to interact with MetaMask. First We will design the new user interface to provide an good experience for the users. Second, we will build this wallet application. It will be our long-term supported product. +To hit this milestone, two month full-time work is needed for all our dev/pm on the software side (Aaron Chen - CTO of Keystone, Zhang XiaoChun - Product Manager, Tian li - Software Engineer), 0.5 month full-time work is needed for our QA engineer & UI/UX designer (Xia MengYun- QA Engineer, Zhang XiaoChun - UX Designer). +Grants are 20k 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 manage their assets with this wallet application. | +| 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. | Application | We will publish the wallet application that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an article that explains how to use this application for the whole Polkadot community. | + +## Future Plans + +Once MetaMask merged its Snap function to the normal version, BTCSnap (developed by Keystone) will be promoted as one of top 3 Snaps on its main page where our snaps would get a huge exposure. In a short term, we plan to develop a series of snaps for different chains and make a “Snaps Bundle” upon our Bitcoin Snap where users could easily switch to different snaps for different chains in one place. In the long term, we’ll continue to build various snaps, not only for transactions, but also Defi, NFT, Game etc for different chains to enrich the Keystone Snaps ecosystem and obviously Polkadot will be one of our top priority. diff --git a/applications/Polkadot_Web_UI.md b/applications/Polkadot_Web_UI.md index 026735db5af..1447abbe970 100644 --- a/applications/Polkadot_Web_UI.md +++ b/applications/Polkadot_Web_UI.md @@ -1,5 +1,5 @@ -# Open Grant Proposal -* **Project Name:** Polkadot UI Web Identicon + Angular Identicon +# Polkadot UI Web Identicon + Angular Identicon + * **Team Name:** RidOne Technologies * **Payment Address:** DAI 0xfA34F566bDDcA92Dc656310F08AC5aE64fC46456 ## Project Overview diff --git a/applications/Polkaholic.md b/applications/Polkaholic.md new file mode 100644 index 00000000000..57fc1f41bf4 --- /dev/null +++ b/applications/Polkaholic.md @@ -0,0 +1,269 @@ +# Polkaholic.io's Multi-Chain Substrate Block Explorer + +- **Team Name:** Colorful Notion +- **Payment Address:** Polkadot 13rTinCWgc38a2wZzme28dFbViQraCowTRjQqFLEWwdMTvFW +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1286#pullrequestreview-1188260010) + +## Project Overview :page_facing_up: + +[Polkaholic.io](https://polkaholic.io) is a Substrate block explorer with high parachain coverage (45+ chains) and is developing multi-chain functionality for the next generation of Polkadot users. Key new multi-chain features (see [Why Polkaholic?](https://polkaholic.io/features)) not widely available in other block explorers: +* monitoring accounts across chains with asset valuations in real-time +* performing historical analysis across chains +* monitoring XCM transfers across chains + +The Polkaholic.io team would like to seek Web3F Level 2 funding for high availability APIs powering the Polkaholic.io UI. These APIs will support Polkadot parachain and dapp developers, and will be used in the Polkaholic.io UI to support useful multi-chain block explorer features for the next generation of Polkadot users: +* Support Polkadot defi users doing multi-chain transfers in and out of any chain +* Support Polkadot dapp and parachain developers doing real-time multi-chain analysis with standardized asset types +* Support Polkadot wallet developers with multi-chain APIs + +It is essential for a public block explorer to be trusted, and while Polkaholic.io code is released under a GPLv3 license at: +* https://github.com/colorfulnotion/polkaholic/ +it is difficult to trust that the indexing is 100% correct by simply auditing the above code and spot checking a few representative results. +The approach Polkaholic.io has taken is an "indexing" approach, where all chain activity is analyzed and stored with additional information (e.g. asset values in USD) in Google Cloud's BigTable/BigQuery/mysql. This is complementary to the approach taken by polkadot.js.org's reference app, where a single endpoint is probed in real-time. + +However, for Polkadot users to *trust* Polkaholic.io's index, all indexed data must be *verifiable* to the fullest extent possible, which we propose to do by augmenting every Polkaholic.io page with: +* (a) browser-based JS that _verifies_ the results shown in any page as being the same as the indexed data using one or more WS endpoints +* (b) server-side JS that continuously (randomly) _verifies_ any key object ( account, block, tx, chain etc. ) returned in any API call against one or more WS Endpoints +Currently, every page on Polkaholic.io shows how to use the Polkaholic.io API to derive the data shown on the page, which we have taken as a design principle. +We propose to take this further, by publishing the code of (a)+(b) alongside these same API calls. If any verification fails, the failure can be automatically logged and used to improve the index (rather than, say, waiting for users to report data issues, or for developers to point out bugs with the indexer code). All chain's random checks can be published as metadata with the chain. As verifications pass and Polkaholic.io approaches 100% verifiability, users should increase trust in the Polkaholic.io index. + +### Project Details + +To illustrate Polkaholic.io's fully working multi-chain UI + APIs, we tabulate 5 representative UI / API calls here: + +#### Chains + +![Chains UI Screenshot](https://cdn.polkaholic.io/screenshots/chains.png) + +* [Chains UI URL](https://polkaholic.io/chains) +* [Chains API Sample call](http://api.polkaholic.io/chains) +``` +curl -H "Authorization: YOUR-API-KEY" "https://api.polkaholic.io/chains" +``` + +* [Chains API Docs](https://docs.polkaholic.io/#chains) + +#### Account + +![Account UI Screenshot](https://cdn.polkaholic.io/screenshots/account.png) + +* [Account UI URL](https://polkaholic.io/account/121Rs6fKm8nguHnvPfG1Cq3ctFuNAVZGRmghwkJwHpKxKjbx#extrinsics) +* [Account API Sample call](https://api.polkaholic.io/account/121Rs6fKm8nguHnvPfG1Cq3ctFuNAVZGRmghwkJwHpKxKjbx) +``` +curl -H "Authorization: YOUR-API-KEY" "https://api.polkaholic.io/account/extrinsics/0x2c8feeab5bd9a317375e01adb6cb959f1fea78c751936d556fa2e36ede425a47" +``` +* [Account API Docs](https://docs.polkaholic.io/#get-account) | + +#### Account XCM Transfers + +![Account XCM Transfers Screenshot](https://cdn.polkaholic.io/screenshots/accountxcmtransfer.png) + +* [Account XCM Transfers UI URL](https://polkaholic.io/account/121Rs6fKm8nguHnvPfG1Cq3ctFuNAVZGRmghwkJwHpKxKjbx#xcmtransfers) +* [Account XCM Transfers API Sample call](https://api.polkaholic.io/account/xcmtransfers/121Rs6fKm8nguHnvPfG1Cq3ctFuNAVZGRmghwkJwHpKxKjbx) +``` +curl -H "Authorization: YOUR-API-KEY" "https://api.polkaholic.io/account/xcmtransfers/0x2c8feeab5bd9a317375e01adb6cb959f1fea78c751936d556fa2e36ede425a47" +``` +* [Account XCM Transfers API Docs](https://docs.polkaholic.io/#get-account-xcm) + +#### Search XCM Transfers + +![Search XCM Transfers Screenshot](https://cdn.polkaholic.io/screenshots/searchxcmtransfers.png) + +* [Search XCM Transfers UI URL](https://polkaholic.io/search/xcmtransfers) +* Search XCM Transfers API Sample Call: +``` +curl -H "Authorization: YOUR-API-KEY" -X POST -H "Content-Type: application/json" -d '{"startDate":"2022-07-03","endDate":"2022-07-06","chainID":"0"}' "https://api.polkaholic.io/search/xcmtransfers" +``` +* [Search XCM Transfers API Docs](https://docs.polkaholic.io/#get-xcm-transfers) + +#### Search XCM Messages (under development) + +![Search XCM Messages Screenshot](https://cdn.polkaholic.io/screenshots/searchxcmmessages.png) + +* [Search XCM Messages UI URL](https://polkaholic.io/search/xcmmessages) +* Search XCM Messages API Sample Call: +``` +curl -H "Authorization: YOUR-API-KEY" -X POST -H "Content-Type: application/json" -d '{"startDate":"2022-07-03","endDate":"2022-07-06","chainID":"0"}' "https://api.polkaholic.io/search/xcmmessages" +``` +* [Search XCM Messages API Docs](https://docs.polkaholic.io/#search-xcm-messages) + +#### Polkaholic.io Backend + +Briefly, the backend is organized as follows: +* A Google Cloud stack (BigTable, BigQuery, mysql) is used in 3 regions (US/EU/AS) to store blocks, txs, accounts, XCM transfers, and XCM Messages +* Blocks, traces, EVM logs for all chains are crawled/indexed from WS Endpoints in realtime with followup hourly analysis and backfill processes. A BigTable and mysql table support each chain, 5 BigQuery tables support each major type of object (extrinsics, transfers, xcmtransfers, xcmmessages, evmtxs) +* XCM Transfers are matched in real time, currently based on asset + address matching + +### Ecosystem Fit + +The Polkadot ecosystem benefits from users being able to transact with their assets on multiple chains easily, through teleporting and the new XCM Messaging system enabling "remote control" over asset states on other parachains. There are many block explorers in the ecosystem (eg subscan.io) but these were architected for users using interacting with a _single_ parachain rather than the dozens of parachains that exist today which are rapidly adding XCM transfers. As users use their wallets to manage their assets on a greater number of parachains, users will need a block explorer, dapps, wallets that takes **multi-chain** account views and multi-chain transfers as central to their UI. Polkaholic.io aims to provide the UI and APIs for the ecosystem to support these multi-chain views. + +Currently, there's no easy way to track XCM transfers, messages and do XCM analytics between chains for individual accounts and with parachains in aggregate. Polkaholic.io proposes to change this, by providing a set of APIs to help Polkadot developers. We believe a suite of verifiable APIs + UI (concerning XCM Messages, XCM Transfers, XCM Analytics) can be used by: + * parachain devs + dapp devs and wallet devs (XCM Messages, XCM Analytics) -- API, used in polkaholic.io + * defi/NFT chain users (XCM Transfers) -- UI +Having a open-source reference implementation can also aid other ecosystem participants in their own development and analytics. +Furthermore, we believe that supplying the concrete **verifiable** browser-based and server-based code will serve as educationally instructive to the Polkadot ecosystem, and be representative of how multi-chain block explorers should work. + +## Team :busts_in_silhouette: + +### Team members / Contact + +- **Contact Name:** Sourabh Niyogi / Michael Chung +- **Contact Email:** sourabh@colorfulnotion.com / michael@colorfulnotion.com +- **Website:** https://polkaholic.io + +### Legal Structure + +- **Registered Address:** 55 E 3rd Ave, San Mateo, CA 94401, USA +- **Registered Legal Entity:** Colorful Notion, Inc. + +### Team's experience + +Key engineers Sourabh Niyogi and Michael Chung have developed Polkaholic.io since Fall 2021. Prior to building Polkaholic.io, Sourabh and Michael worked in decentralized social networking protocol development + privacy-preserving contact tracing (Wolk), mobile advertising real-time bidding algorithm design and analytics (CrossChannel/MdotM). Sourabh has founded social + web advertising startups (Social Media Networks) in the SF Bay and spent time doing computational cognitive science and machine vision research at MIT. Michael hails from UC Berkeley. + +### Team Code Repos + +- https://github.com/colorfulnotion/polkaholic +- https://github.com/colorfulnotion/docs.polkaholic.io +- https://github.com/sourabhniyogi https://www.linkedin.com/sourabhniyogi +- https://github.com/mkchungs + +## Development Status :open_book: + +Polkaholic.io is a fully working block explorer that currently shows initial UI + API implementations, including indexing across 40+ chains and 90+ chain pairs. We are increasing XCM Transfers coverage (95% coverage) and are developing XCM Messages + Analytics Tools. + +## Development Roadmap :nut_and_bolt: + +As part of Milestone 1 + 2, the Polkaholic team will: +- Add _verifiability_ to all key Polkaholic.io pages: chain, block, extrinsics/txs, account with (a) browser-based JS and (b) server-side JS +- Add continuous _verifiability_ using server-side JS and publish % of verification checks per chain as chain-specific metadata +- Extend polkaholic.io functionality with XCM Transfers + Message Tools, with _verifiability_ of DMP, UMP, HRMP XCM transmissions +- Ensure the polkaholic.io repo be started with an empty Google Cloud project +- Publish blog posts on the XCM Transfers and Messages Tooling + +### Overview + +- **Total Estimated Duration:** 12 weeks +- **Full-Time Equivalent (FTE):** 2.0 FTE +- **Total Costs:** 30,000 USD. + +The following sheet details our proposed deliverables, organized by Site Area and Verification Function: + +[https://docs.google.com/spreadsheets/d/1w9xIhyHgB05PgXEVDMyazRYkYvBD3ETaIbWb8X2DKYc/edit#gid=323796891](https://docs.google.com/spreadsheets/d/1w9xIhyHgB05PgXEVDMyazRYkYvBD3ETaIbWb8X2DKYc/edit#gid=323796891) + +* **Section 1** describes how site areas on polkaholic.io map to a set of verification functions that will verify polkaholic.io web page / API data +* **Section 2** describes how _Verification Functions_ (prioritized based on perceived audience importance) will be delivered in Milestone 1 + 2 + 3 + +For each *verification function*, there will be two parallel deliverables: +1. _Browser-based code_: UI will have a "Verify" button in the area (same as "curl" call at the bottom of most pages) showing the code and running the code +2. _Server-side code_: A continuous process will randomly select an object (ie finalized block, extrinsic, event, or account) and run a similar server-side verification function, logging pass/fail results exposed in the UI +The browser-based code can be tested directly on the site, whereas logs of the server-side code will be exposed in the UI (which objects passed vs failed a verification function). + +Both forms of code will have almost identical core and rely on the polkadot JS API to do RPC calls like [this](https://github.com/colorfulnotion/polkaholic/blob/main/substrate/test/testGetAuthor.js#L18-L26), which gets the block. + + +Disclaimer on limitations of verifiability: +* Only chain data can be verified -- asset valuations, TopN account, login information are not feasible. +* Only _observed_ indexed data can be verified -- if the indexer hasn't observed an account (a secret genesis account) through its indexing processes, neither the UI or the continuous verification processes can discover that its missing without specialized reasoning +* Some chain data is incorrect and has been corrected in the polkaholic backend +These are marked "INFEASIBLE". Otherwise, we have attempted to be as comprehensive as possible, but skip verifiability of EVM chain data (and images) for simplicity / focus reasons, which are marked "NOT ATTEMPTING". +Other practical considerations: +* because traces are computationally expensive, and some verification requires traces (XCM message sending, see Milestone) we cannot run continuous verification except on our own full archive nodes (for which we do 12 or so out of 45+ parachains) +* new parachains often do not expose archival endpoints for some time. + +Precise deliverables for each milestone are shown in yellow cells in **Section 2** and are referenced below. + +### Milestone 1 — Implement Verifiability for Chain, Block, Extrinsics, Accounts + +- **Estimated duration:** 4 weeks +- **FTE:** 2.0 FTE +- **Costs:** 10,000 USD + +We will deliver verifiable functions concerning: + +* Block Data: `verifyBlockData`, `verifyBlockDataByBlockHash` +* Extrinsics: `verifyExtrinsicParams` +* Events: `verifyEventParams` +* Account Balance: `verifyAccountBalance` +* Account Addresses: `verifyAccountSS58Address` +* Account Transfers: `verifyEventParams_transfer` + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0A. | License | GNUv3 | +| 0B. | Documentation | We will provide: (a) **inline documentation** of the core crawling and indexing processes (b) how to setup polkaholic.io from an empty Google Cloud project | +| 0C. | Testing Guide | We will post a Google Doc to show the above verifiable functions in action: (a) For the browser-based Verification functions, this doc will show how each key site area has a "Verify" button which will show the browser-based code and run the check for the key object (block, extrinsic, account for that page), returning whether the test passed or failed; (b) For the server-based Verification functions, we will document how to configure run the continuous verification, how pass/fail are logged in the database and exposed in the UI. +| 1. | UI Augmentation: Browser-based JS for Verifiability | For all site areas shown in Section 2 "Milestone 1" Deliverables, we will add browser-based code to verify results by utilizing Polkadot RPC calls to WS Endpoints. | +| 2. | Backend Augmentation: Server-side JS for Verifiability | For all key pages, we will publish similar server-side code that also verifies results. | +| 3. | Blog Post | We will publish blog posts that show the results of our UI Augmentations. | + +We expect any observed failures in verification to result in indexing fixes. + +### Milestone 2 — Implement Verifiability for Account Rewards, Transfers, Crowdloans (Direct), Proxy + Multisig accounts + +- **Estimated duration:** 4 weeks +- **FTE:** 2.0 FTE +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0A. | License | GNUv3 | +| 0B. | Documentation | We will provide **inline documentation** of the continuous verification processes implemented in Milestone 1 and 2 | +| 0C. | Testing Guide | We will augment the Google Doc Testing Guide to show the above verifiable functions in action for the new site areas covered by the verification functions. | +| 1. | UI Augmentation: Browser-based JS for Verifiability | For all site areas shown in Section 2 "Milestone 2" Deliverables, we will add browser-based code to verify results by utilizing Polkadot RPC calls to WS Endpoints. | +| 2. | Backend Augmentation: Server-side JS for Verifiability | For all site areas shown in Section 2 "Milestone 2" Deliverables, we will publish similar server-side code that also verifies results. | +| 3. | Continuous Testing | Using the server, Continuous random checks on every chain will be applied, outputting verification rates for each chain indexed. | +| 4. | Blog Post | We will publish blog posts that show the results of our UI Augmentations. | + +Same as above, but executing on a different set of verification functions: +* Rewards - `verifyEventParams_rewards` +* Proxy - `verifyAccountProxy(chainID, pubkey, proxyAddress, proxyType)` +* Multisig accounts - `verifyAccountMultisig` +* Identity information - `verifyAccountIdentity` +* Crowdloans (Direct) - `verifyEventParams_crowdloan` +* EVM Tx - `verifyEVMTx`. +* Trace - `verifyBlockTrace` +* Spec Version - `verifySpecVersion` + +Again, we expect any observed failures in verification to result in indexing fixes targeted + +### Milestone 3 — Implement Verifiable Timeline UI for XCM Transfers and Messages [UMP, DMP, HRMP] + +- **Estimated duration:** 4 weeks +- **FTE:** 2.0 FTE +- **Costs:** 10,000 USD + +Similar to the above, in this milestone we develop tooling for XCM Transfers + Messages, which we believe to be central to the success of the Polkadot ecosystem. We propose to build an XCM Timeline UI with verifiability of XCM transmissions for the 3 "common" XCM protocols (DMP, UMP, HRMP) that are already widely between several dozen parachains. A prototype timeline can be seen [here](https://polkaholic.io/timeline/0x1102d5d85d5047bcaf61793d7dc6944c813691c1ce9ced54d0b0470ffc475743) and is linked from the [XCM Transfers page](https://polkaholic.io/chains#xcmtransfers) which shows all indexed XCM Transfer. This XCM Timeline UI and existing XCM Transfer Indexing will be backed by 3 core verification functions that we will develop: + +* `verifyXCMMessageDMP` +* `verifyXCMMessageUMP` +* `verifyXCMMessageHRMP` + +which each will verify that a extrinsic's XCM message(s) are routed through a relaychain / parachain specific to one of these 3 protocols. A simple verification process will involve verifying whether the XCM Message from a sending chain has the expected extrinsics/events/traces on receiving and downward chains. + +We will attempt to adapt our XCM Timeline tool to support XCM instructions that contain XCM messages (`transferReserveAsset`, `depositReserveAsset`, `initiateReserveWithdraw`, `initiateTeleport`) within that scope, thus potentially involving more than 2 chains. + +We will restrict our XCM timeline tool to DMP, UMP, and HRMP/XCMP and our restrict our scope to existing v2 and v3 messages. + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0A. | License | GNUv3 | +| 0B. | Documentation | We will provide: (a) **inline documentation** of the **XCM Indexer** and how the matching process between sending and receiving chains works for **XCM Messages**; (b) APIs for retrieving indexed XCM messages + transfers with XCM v2+v3 | +| 0C. | Testing Guide | We will augment the Google Doc Testing Guide to (a) explain how the XCM Timeline UI "Verify" functionality can be accessed and used to test each of the 3 XCM protocols in scope; (b) explain how recursive XCM messages within the same scope can be covered. | +| 1. | UI Augmentation: XCM Messages Verifiability | Using the same approach as in Milestone 1 and 2, we will augment the Polkaholic.io with browser-based JS and server-side JS to support verifiability of XCM Results. | +| 2. | Continuous Testing | Using server-side JS, continuous random checks on recent XCM Messages chain will be applied, outputting verification rates. | +| 3. | Blog Post | We will publish a blog posts that demonstrate the Polkaholic.io XCM Messages and Transfers API and new Timeline functionality. | + +We expect any observed failures in verification and the XCM Timeline tool to result in indexing fixes targeted at XCM specifically. + +## Future Plans + +Polkaholic.io intends to operate its multi-chain block explorer for Polkadot users long-term, as well as supporting parachain developers and dapp developers with XCM tooling and APIs that just work. + +## Additional Information :heavy_plus_sign: + +* Polkaholic directly addresses this RFP for a [Multi-Chain Block Explorer](https://github.com/w3f/Grants-Program/blob/master/rfps/open/multi-chain-block-explorer.md) +* Bill@Web3F recommended we develop a XCM call graph UI, supporting this RFP for [XCM library & tools](https://github.com/w3f/Grants-Program/blob/master/rfps/open/xcm-tool.md) +* We were recommended by Radha to look at the Grants + Treasury Program and through June 2022's Polkadot Decoded event after submitting a polkadot.js PR. +* We welcome active collaborations with parachains, wallet developers, and projects engaged in "remote control" XCM that are interested in XCM Transfers + Messages APIs and related tooling. diff --git a/applications/Polkawatch.md b/applications/Polkawatch.md index 3ad78603056..981f45c055e 100644 --- a/applications/Polkawatch.md +++ b/applications/Polkawatch.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Polkawatch -- **Project Name:** Polkawatch - **Team Name:** Valletech AB - **Payment Address:** 0xA39bD6af74f8c317F45137d2ED7F4e13176d916B (ETH/DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 diff --git a/applications/Preparing Polkadot pallet_balances for Formal Verification.md b/applications/Preparing Polkadot pallet_balances for Formal Verification.md new file mode 100644 index 00000000000..c3950d1f0e5 --- /dev/null +++ b/applications/Preparing Polkadot pallet_balances for Formal Verification.md @@ -0,0 +1,308 @@ +# Preparing Polkadot's pallet_balances for Formal Verification using the Inference Framework + +- **Team Name:** Inferara Corp. Ltd. +- **Payment Address:** 13zmwfLi7SSVeFsWybmPNEu7awsZzfn29cTAMLbh2baG7CLa (DOT & USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + + +## Project Overview :page_facing_up: + +### Overview +Research potential ways to integrate formal verification into the development process of Polkadot, starting with `pallet_balances`. + +- A brief description of your project. + +This project is an R&D initiative to further secure Polkadot and subsequent parachains. With the recent increase in discussions of stablecoins across all ecosystem, we observed the benefit of gaining mathematical assurance for the safety of functions within `pallet_balances` for existing and future uses. As Polkadot continues to grow so should the level of scrutiny when it comes to security. +Since pallets are an essential part of the Polkadot infrastructure, we want to take a deep look at exactly how the current logic functions. `pallet_balances` is used by every token on Polkadot. Within `pallet_balances`, the `fungible` traits are what will be researched specifically. +We plan how to apply our Rocq-based framework [Inference](https://github.com/Inferara/inference-language-spec/blob/main/README.md) to Polkadot’s fungible trait set. +Adaptation of the `fungible` trait set for formal verifications within our non-deterministic WASM framework will enable complete trait extraction with validated semantic mapping ready for formal specification. + +- An indication of how your project relates to / integrates into Substrate / Polkadot / Kusama. + + Inference is designed as a domain‑specific formal specification language. By blending conservative procedural syntax with novel semantics of controllable non-determinism, it aims to let developers write formal specifications in a way that resembles writing unit tests. Designed with bearing similarities to classical imperative language in mind, Inference can be quickly understood and used by existing Polkadot developers. Through intermediate representation of purposefully extended WASM, such specifications are supposed to be translated into Rocq theories, allowing computer-assisted formal verification in a state-of-the-art interactive theorem prover. Inference seeks to bridge the gap between theorem proving and practical application development in blockchains. This approach provides a way to integrate formal verification into the development process of Polkadot projects. + +- An indication of why your team is interested in creating this project. + +Our team always has security in mind as the most important part of any infrastructure, chain, or protocol. As mentioned in the previous section, we plan to make theorem proving more accessible for Web3 development. + +Due to the powerful capabilities of the Polkadot ecosystem, we would like to highlight its strengths by applying our non-deterministic approach to formal verification. By being an open-source project, we hope it will be the starting point to inspire more development and research opportunities for the Polkadot ecosystem. + +We want to enable more developers and researchers to explore formal verification by mitigating the common hindrances. + +- An indication if your project is academic research, i.e., intended to be published in an academic peer-reviewed venue, or a technical one, to be published as a technical report on the internet. + +The research will be published as a techincal report on the internet with a dedicated github repository including documentation and source code. + + + +### 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): + +- The problem(s) that you want to investigate, and why these are important. + +The Polkadot ecosystem, with its complex, parachain architecture, faces significant challenges in ensuring the correctness and security of its runtime logic, consensus mechanisms, and cross-chain interactions. Traditional testing and auditing methods, while useful, are insufficient to guarantee the absence of critical vulnerabilities. However, existing formal verification methods impose a steep learning curve, requiring developers to master complex mathematical logic just to comprehend formal specifications—let alone write or verify them. This creates a significant barrier to adoption, to the point that no one even considers it because of a major inhibiting effect on the speed of development. + +To address this challenge, this research proposes a novel verification paradigm where specifications are expressed in an imperative style, closely resembling traditional unit tests. By shifting from declarative formal logic to test-like specifications, the approach aims to make formal verification more intuitive and accessible for Polkadot developers. The goal is to enhance security without sacrificing productivity, enabling rigorous correctness guarantees for key components such as NPoS consensus, parachain interoperability, and on-chain governance—while minimizing the need for deep expertise in formal methods. + +- Research questions/hypothesis. + +Can Polkadot’s fungible trait set—a core component of the asset management system—be formally specified in an imperative, test-like manner without sacrificing mathematical rigor? + +Our hypothesis is that by redefining formal specifications as controllably non-deterministic assertions mirroring unit tests, developers can definitively state key properties (e.g., conservation of supply, secure transfers, and correct access control) while avoiding the complexity of mathematical descriptions. This work will evaluate whether such an approach can achieve practical adoption by encoding the `fungible` trait’s logic in an **Inference verification framework**, and paving the road to **computer-assisted check of compliance** with desired invariants. + +The outcome could set a precedent for scalable, developer-friendly verification across Polkadot’s runtime modules. + +- The methodology that will be applied. + +This research will apply the under-development **Inference DSL framework**—a specification language with unit-test-like syntax—to formal verification of Polkadot's `fungible` trait. The methodology focuses on: + +1. **Formal Modeling**: Developing a comprehensive formal model of the `fungible` trait's core operations (`transfer`, `mint`, `burn`) and their invariants (supply conservation, authorization rules) using the DSL's imperative style. +2. **WASM Compilation**: Compiling these specifications into specialized WASM modules that incorporate controlled non-determinism to model para-virtual branching. +3. **Validation**: Rigorously validating that the compiled WASM artifacts correctly encode the intended behavior through systematic example-based testing and verification. + +The WASM modules will serve as formal foundations for future **Rocq-based deductive reasoning**, though their theoretical formalization falls outside the current scope. In the next stages, this work will demonstrate how Polkadot's runtime developers can leverage novel verification ideas to write intuitively comprehensible specifications while maintaining a path to full formal verification. + +- The expected results and how they would be double-checked by the grants team (reproducibility of the data analysis). + + **Expected Results**: + - WASM modules enabling future verification. + + **Reproducibility**: + - Open-sourcing all specifications and WASM modules. + - Providing step-by-step guides for the grants team to confirm correspondence between WASM modules and `fungible` traits. + +- Research for relevant related work or declare how the literature review will be conducted. + + **Related Work**: + - Existing formal verification tools for blockchain (e.g., **K-framework, TLA+, CertiK**). + - Prior work on imperative-style formal methods (e.g., **Dafny, F***). + - Polkadot-specific runtime security research (e.g., **FRAME security audits**). + + **Literature Review Methodology**: + - Systematic review of academic papers (IEEE, ACM) and industry reports (Web3 Foundation, Parity). + - Comparative analysis of existing Polkadot verification efforts vs. our proposed approach. + + + + + +- Intended venue for results publication and the timeline for publication. + + **Publication Venues**: + - **Academic**: *IEEE S&P Blockchain Workshop, ACM CCS* (if theoretical contributions are substantial). + - **Industry**: *Polkadot Research Portal, Substrate Developer Hub*. + + + +### 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 research project is a security enhancement to the Polkadot ecosystem. As a research endeavor, it doesn't directly interact with users or the community like a typical DApp or development tool would. Instead, its value is that it will enhance the overall robustness of the Polkadot ecosystem. Although the initial goal of this proposal is to prepare the ground for a specification of `fungible` trait to illustrate semantic mapping between traits and the WASM model, with continued research, it allows for more impactful results. Through the continued research this proposal enables, it could lead to even more significant advancements and potential improvements for security enhancements. + +This could include potential findings of unexpected code behavior or bugs through further completed formal verification. + +- Who is your target audience (parachain/dapp/wallet/UI developers, designers, your own user base, some dapp's userbase, yourself)? + +The main target audiences are protocol researchers and developers within the Polkadot ecosystem. For researchers, it includes those who are already familiar with formal verification, as well as those who are interested in starting while benefiting from a less steep learning curve. + + +- What need(s) does your project meet? + +Our project focuses on the need to explore additional formal verification methods to further enhance the security of Polkadot. This is a novel approach, complicated but of great benefit for Polkadot to stay innovative. + +- How did you identify these needs? Please provide evidence in the form of (scientific) articles, forum discussions, case studies, or raw data. + +For the needs of formal verification, there have been many things we have identified as needs. In regard to this research project, we originally identified these needs through observations of the Polkadot forum. While reading about the [Business Development update](https://forum.polkadot.network/t/a-polkadot-hub-launch-update-from-business-development-group-april-2025/12361), we observed the future goals, related to `pallet_assets`. Although this is where the interest began, we have turned our attention solely toward `pallet_balances` for further study. What began as a regular observation on the status of [Polkadot Hub](https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs) turned into further exploring the Polkadot SDK docs from Paritytech. + +- Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem? + +No. + + - If not, are there similar projects in related ecosystems? + +Similar Projects in related ecosystems + +https://pruvendo.com/ - Formal specification and Deductive formal verification + +https://formal.land/ - Similar Rust-based formal verification + +[Certora](https://www.certora.com/) - As Certora’s Verification Language (CVL) and Prover are tightly coupled with Solidity, it would be easier to recreate something similar from the ground up instead of trying to adapt its existing tools if used outside of the Ethereum ecosystem. + + +Another core difference between Inferara and Certora is the level of abstraction behind core mathematical formalism. Certora has a more classical approach to rule-based invariant checking that roughly corresponds to first-order logical statements. It somewhat limits the expressive power of spec, as more complex properties sometimes are hard to state in such restrictive semantics, but allows automated proof generation by SMT-solvers. We, on the other hand, are trying to build a language that would allow imperative-like equivalent of higher-order logic formulas (much more expressive), targeting computer-assisted (not fully-automated) proving techniques. + + +## Team :busts_in_silhouette: + +### Team members + +- Name of team leader + + Georgii Plotnikov (Rust Lead) + +- Names of team members + + Maxim Savchenko (Formal Methods Lead, PhD in mathematics) + + +### Contact + +- **Contact Name:** Georgii Plotnikov +- **Contact Email:** georgii@inferara.com +- **Website:** [Inferara.com](https://inferara.com) + +### Legal Structure + +- **Registered Address:** + +〒810-0041 日本 福岡県福岡市 中央区大名2-6-11 + + 810-0041 2-6-11 Daimyo, Chuo-ku, Fukuoka-shi, Fukuoka, Japan + +- **Registered Legal Entity:** + +Inferara Corp. Ltd. + +### Team's experience + +**Georgii Plotnikov** + +Writing code since 2013\ +Developing Web3 since 2022\ +Started [Inferara](https://inferara.com) in Jan 2024\ +[St. Petersburg Polytechnic University](https://english.spbstu.ru/), Mathematical modeling of information systems, MS. + + +**Maxim Savchenko**\ +Researcher since 2005\ +MSU Algorithmic Languages, MS\ +[St Petersburg University](https://english.spbu.ru/), [Influence of additional information asymmetry on the solutions of non-antagonistic games](https://disser.spbu.ru/zashchita-uchenoj-stepeni-spbgu/882-savchenko-maksim-alekseevich.html), PhD\ +[Mathnet Publications](https://www.mathnet.ru/php/person.phtml?option_lang=eng&personid=147678) + + + + +### Team Code Repos + +- https://github.com/Inferara/tree-sitter-inference +- https://github.com/Inferara/inference-language-spec +- https://github.com/Inferara/inf-wasm-tools +- https://github.com/Inferara/merkle-tree-wasm-spec + + +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/0xGeorgii +- https://github.com/Keyholder + + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/0xgeorgii/ + +### Google Scholar Profiles (Or other research indexer profile, ex. Researchgate) + +- [Mathnet Publications](https://www.mathnet.ru/php/person.phtml?option_lang=eng&personid=147678) + +## Development Status :open_book: + +If you've already started working on your project or it is part of a larger project, please provide a link and a description of the research here. In any case, please provide some documentation on the research and other work you have conducted before applying. This could be: + +- We have provided several code repositories in the previous section +- Our papers are available on our website [here](https://www.inferara.com/en/papers/) +- Blog post titled: [New Approach to Formal Verification Methods for Combating Vulnerabilities in Smart Contracts](https://www.inferara.com/en/blog/new-approach-to-formal-verification-smart-contracts/) + + +## Development Roadmap :nut_and_bolt: + +### Overview +- **Total Estimated Duration**: 1 Month +- **Full-Time Equivalent (FTE)**: 1.25 FTE +- **Total Costs**: $10,000 +- **DOT%**: 50% + +### Specific Deliverables + + +We are aiming to prepare verification of `pallet_balances` adherence to some of the following properties (preliminary list, subject to changes depending on research progress): +1. **Conservation of Total Issuance** + The total issuance must always equal the sum of all account balances (free + held) plus any imbalances (credits/debts) that haven't been handled. +2. **Non-Negative Balances** + No account should ever have a negative free or held balance. +3. **Existential Deposit (ED) Invariant** + No account should have a total balance (free + held) strictly between 0 and ED (exclusive). If it does, the account should be reaped. +4. **Spendable Balance Constraint** + The spendable balance (free minus holds and freezes) should never be negative. +5. **Hold and Freeze Consistency** + Holds are cumulative: the total held is the sum of all holds. Freezes are not cumulative: the effective freeze is the maximum of all freezes. +6. **Transfer Properties** + Accounting preconditions and postconditions. +7. **Slashing Invariant** + When slashing a hold from an account, the held balance and total issuance is reduced by given amount. +8. **Imbalance Handling** + When an imbalance (credit or debt) is dropped, it should adjust total issuance. + +The finalized list of formal properties will be refined and re-defined in research artifacts. + +Regarding compiled module our primary targets for annotation are points of interaction between `pallet_balances` and its execution environment. In WASM architecture this would be imported and exported function references. All meaningful externally callable routines of the module will be properly documented, including their calling conventions (in most generic sense, as in "what needs to be done to form arguments and parse results if we manually call WASM?") and conceptual relations to the `fungible` trait set. Also, every external routine that is called from inside of the module will receive the same treatment, with comprehensive description of its suppositions, adherence to which is required for correct execution. + +As for acceptance criteria we propose to use [fungible conformance tests](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/support/src/traits/tokens/fungible/conformance_tests) that will be executed with the logic preserved and included into the the research repository with the prepared for formal reasoning `pallet_balances` code. That said, the reasoning ready palette code must pass all conformance tests. As this testing module can not be backported to support the new version of `pallet balances` we will recreate a full semantic equivalent of this test-suite for manual linkage. + +### Milestone 1 of 1 +- **Estimated duration**: 1 month +- **FTE**: 1.25 +- **Costs**: 10,000 USD + +| Number | Deliverable | Specification | +|--------|-------------------------|--------------------------------------------------------------------------------------------------------------| +| 0a. | License | MIT. | +| 0b. | Documentation | We will provide informative documentation on our research process and findings. This will be in a dedicated GitHub repository. Will also include 0c-0d deliverables and research artifacts. | +| 0c. | Reproducibility | We will provide step-by-step guides for the grants team to know what we have done. Includes rust code of the functionality that has been researched and resulting byte code. We will provide .rs files for the fungible conformance tests. | +| 0d. | Final Research Article | We will publish a detailed research article to the Github repository and our website that explains our research findings and results. This includes the reproducibility guide of the 0c deliverable, notably WASM binary compilation artifacts. _Textual_ description of `fungible` traits specification along with discovered assumptions regarding execution environment, required for its implementation. All public functions, involved in implementation of traits Inspect, Unbalanced, UnbalancedHold, Mutate, InspectHold, MutateHold, UnbalancedHold, InspectFreeze, MutateFreeze and Balanced. This article will include a cleaned up and annotated WASM module of `pallet_balances`. Includes Rust code that is distilled and ready to reason about. Ordinary unit tests to confirm its faithfulness to the original in a classical sense. This prepares `pallet_balances` for future reasoning. | + + + + + +## Future Plans + +Please include here + +- How you intend to use, enhance, and promote your project in the short term + +We will continue to share our progress and interesting discoveries during the research. + +- How do you intend to finance the project's long-term maintenance and development? + +We anticipate that this research will pave the way for further exploration into implementing a theorem catalog and fully applying our verification methodology to Polkadot, thereby enabling a clear path to implementation verification. + +- If we would sign the grant, what would you envision to be the next step(s) after its completion? Would you continue to work on this, and if yes, in what capacity? + +After the completion of this grant, we would use the bytecode from the research artifacts of `pallet_balances` for further reasoning. This enables us to formalize and define formal properties for this substrate. + +The next step would be to ensure the soundness of the properties. + +Here is a detailed description of how we envision the future research steps: +### Research findings and next steps. +Our general plan for the complete research consists of three major phases: +1. **Land clearing**. Our in-development methodology for program verification relies on reasoning about already compiled WASM modules, so we can not treat them as black-box objects that just need to work somehow. It is important to isolate meaningful code, that specification should be covering, from the surrounding elements of infrastructure, that may slip into compiled modules due to the uncontrollable complexities of build process. To be properly specified, `pallet_balances` must be first stripped of everything not directly related to its core functionality. If there are any algorithm subtasks, currently delegated to external frameworks, they must be either re-implemented inline, or comprehensively annotated to become explicit suppositions of future spec. Basically, `pallet_balances` should start looking like it was hand-written with a systematically minimalist approach. +2. **Specification design**. Using our in-development language Inference, we write formal specification of traits implemented in subject module, with regard to suppositions, discovered in the previous step. By nature of our tool-chain, this formal specification itself targets a variety of WASM for compilation, though the resulting module is not executable due to its reliance on the controllable non-determinism to express para-virtual branching. +3. **Formal verification**. We link together WASM modules of the covered pallet and its formal specification in our in-development Coq-based reasoning environment. Such linking produces Coq theories, that can be roughly summarized as "If non-deterministic execution was possible, this code would terminate successfully". Proving resulting theories by logical means essentially implies, that subject module adheres to the specification in all cases. +This particular grant application covers only the first point of this plan (Land Clearing), but we are looking forward to continuing our work on the next steps, depending on eligibility of results and your concernment. + + +As for capacity, for any future grants we hope to increase the existing team capacity. Such an increase would be from FTE of 1.25 to 2. The increase of capacity opens up the opportunity to involve more individuals into the research project. The scale of the team depends on the grant size of course. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Personal recommendations by @bhargavbh & @takahser + +- Previous grants you may have applied for. + +We have not applied for any other Polkadot/Kusama grants. diff --git a/applications/Primis.md b/applications/Primis.md new file mode 100644 index 00000000000..e3b5e733bcd --- /dev/null +++ b/applications/Primis.md @@ -0,0 +1,148 @@ +# Primis + +- **Team Name:** Primis +- **Payment Address:** 0x0Ad212E301AD590f4E70dA0c0Aa2912273cB4098 (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + + +## Project Overview + +### Overview + +Primis Desktop provides a one-stop Web3 integrated client for the Polkadot ecosystem. + + +### Primis Web3 Desktop for Polkadot + +**Primis Wallet** + +Primis Desktop Wallet is the best tool to manage multi-chain assets on the Polkadot ecosystem, such as Polkadot, Kusama, and other parachains. Asset management mainly includes digital/NFT assets checking, sending, receiving, and trading records on the Polkadot ecosystem. + + **P2P Chat** + +Primis Desktop provides encrypted chat groups for Polkadot ecosystem users to discuss decentralized Gov2 governance and Proposal freely. ZK-Proof technology will be combined into Primis chat groups to offer more privacy and decentralized DAO governance space. + +Primis Desktop could automatically create encrypted chat groups for Polkadot ecosystem DApps, each DApp has its own independent chat group. + +- Channels For Chat +image + + +- P2P Chat +image + + + +**Subscribe** + +Primis Desktop also is a place for users to subscribe to Polkadot decentralized notifications like EPNS. Initially, Primis Desktop will provide asset change notifications for Polkadot, Kusama, and other parachains. More on-chain DApps notifications to exploit in the future. + + +**Primis Web3 PNS Browser** + +Primis Desktop will gestate a Chrome-compatible PNS browser for the Polkadot ecosystem, allowing Polkadot ecosystem users to access Web2 pages and interact with Web3 DApps freely. Primis Web3 PNS Browser supports Polkadot ecosystem PNS domains’ resolution and visit. + + +Unlike traditional browsers such as Chrome, Brave, and Web2 centralized Cloud Service, Primis Web3 PNS Browser is based on a data relay network, where access and application data are transmitted to clients or Primis terminals through a relay network of Primis nodes. + +**DApp Self-Hosting Platform** + +Primis Desktop provides the plug-in function. All DApps on the Polkadot ecosystem can integrate and deploy on the Primis relay node network and upgrade and confirm through the reliable connection contract in a smart contract to ensure applications’ security. + +*** +Due to being the first Web3 desktop, Primis will interact with Polkadot's Web3 Ecosystem and bring the brand-new desktop concept to web3 users of Polkadot. + +All of our teammates truly believed in the Web3 Revolution! That's why we want to boot this Web3 project. + +### Tech Stack + + +Supported Chains: Polkadot, Kusama, and other Parachains such as Acala, Astar, and Moonbeam. + +Client language: Electron, React + +Server language: Nodejs + +P2P language: Golang + + +### Ecosystem Fit + +Primis is the first blockchain project known as the web3 desktop. And we want to attract more other ecosystems' web3 users to Polkadot ECO. Since primis is based on the concept of Web3, it has strong relationships with the most famous web3 organization W3F, and must be born here. + + +## Team + +### Team members + +Primis team has rich experience in the fields of the public chain, infrastructure, and defi. Team members' info will be released after reviewing. + +### Contact + +- **Contact Name:** Andy +- **Contact Email:** Contact email (contact@primis.cc) +- **Website:** primis.cc + +### Legal Structure + +- **Registered Address:** This info will be released after reviewing +- **Registered Legal Entity:** Also, this info will be released after reviewing. + +### Team's experience + +Primis team has developed some blockchain projects, like [Metauce](metauce.org) + +### Team Code Repos + +[Github](https://github.com/Primis-Labs/client) + + +### Team LinkedIn Profiles (if available) + +This info will be released after reviewing + +## Development Status + +Primis Team already completed the designing work of Primis Desktop and started working on Milestone 1 Tech Tasks. + +## Development Roadmap + +### Overview + +- **Total Estimated Duration:** 6 weeks +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 10,000 USD + +### Milestone 1 - Polkadot ECO Wallet + +- **Estimated duration:** 6 weeks +- **FTE:** 3 +- **Costs:** 10 ,000 USD + +| Number | Deliverable | Specification | +| -----: | ------------------------------ | ------------------------------------------------------------ | +| 0a. | License | MIT | +| 0b. | Documentation | We would provide an **inline document** of code and tutorial docs that explain how users can install it. | +| 0c. | Testing Guide | Unit tests will cover all core functions to ensure functionality and viability. We will describe how to run the tests in the tutorial. | +| 0d. | Docker | Wallet application does not require Docker, and we would provide a client for users to install under Windows/MacOS system. | +| 1. | Build app structure | We will have the core structure of the application in place. | +| 2. | Implement wallet view | Create, import, view, and transfer functions will be provided by the integrated Polkadot wallet.| +| 3. | Build Polkadot ECO wallet | Checking, sending, receiveing assets of Kusama, Moonbeam, and Acala will be provided for Primis users. | +| 4. | NFT assets management | NFT assets can be viewed, sent, and received under Primis. | +| 5. | Setup Primis NFT avatar | Users can set NFTs as their wallet avatars. | + +## Future Plans + +Short-term: After finishing all milestones, the users' amount of Primis web3 desktop will be over 50K. + +Long-term: The most influenced Web3 desktop + + +## Additional Information + +**How did you hear about the Grants Program?** Web3 Foundation Website + + + + + diff --git a/applications/PrivaDEX_aggregator.md b/applications/PrivaDEX_aggregator.md new file mode 100644 index 00000000000..8023c2b8596 --- /dev/null +++ b/applications/PrivaDEX_aggregator.md @@ -0,0 +1,239 @@ +# PrivaDEX: Cross-Chain DEX Aggregator MVP + +- **Team Name:** OCamlMyCaml +- **Payment Address:** 13BpdtqDLM25KfCb5ttYy1opDP1sHmUNQka8QZi5DqQ3UGAV (Polkadot - USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + +### Overview + +PrivaDEX is a cross-chain DEX aggregator that enables cross-chain trading and unifies Polkadot's fragmented DeFi ecosystem. + +#### DeFi in Polkadot is *frustratingly fragmented* +There are currently five parachains that each hold 10-35% of Polkadot's total DEX TVL, with four more parachains that plan to soon launch (or have recently launched) their flagship DEX. Despite having so many trading venues available, 80% of DEX users trade on a single parachain - and are thus limited to 10-35% of the available trading opportunities [1]. +![Pie chart](https://raw.githubusercontent.com/kapilsinha/privadex/main/media/dex_usage_pie_chart.png) + +The reason is simple; cross-chain trading is far too cumbersome. Executing a cross-chain swap is a 5 minute endeavor that requires several DEX swaps, manually bridging tokens, and waiting for all the transactions to be processed [2]. In short, DeFi in Polkadot is frustratingly fragmented. + +[1] Based on results from surveys like [this one](https://docs.google.com/forms/d/16p3ti-VbX_yrU74TqZlxNapYFsISAOJKaM0B6B6jT1M), collected from users of StellaSwap, BeamSwap, ArthSwap, and AcalaSwap. + +[2] Coming from a trading background, Kapil developed and ran systematic trading strategies in the Polkadot ecosystem a few months ago. At the time, liquidity was particularly scarce in light of the Nomad bridge hack and the Acala hack, necessitating multi-venue trading. Nevertheless, he found it impossible to systematically trade cross-chain due to the lack of existing automation. + +#### PrivaDEX defragments DeFi +PrivaDEX automates cross-chain messaging and smart order routing so that traders don’t spend those 5 minutes manually executing one cross-chain trade. Now it's one step. + +By pooling liquidity from several DEXes across chains, PrivaDEX has access to more liquidity than any existing DEX. Further, it optimizes order splitting/routing to minimize price impact and achieve the best prices for users. PrivaDEX makes it 1-click-easy to efficiently trade across parachains. + +### Project Details +#### Architecture +![Technical flow](https://github.com/kapilsinha/privadex/blob/main/media/technical_flow.png?raw=true) + +Moving left to right in the above diagram, the development stack consists of +1. Typescript and GraphQL for the blockchain indexing to generate price feeds +2. Phat Contract Rust code, which looks like ink! smart contract code and acts like an AWS Lambda (off-chain stateless/serverless computing) +3. React for the swap UI + +#### Proof-of-Concept +We have developed a proof-of-concept for the executor module [here](https://drive.google.com/file/d/1jmPsCUfRWBJX6oRYvmAUGISYzbz2U0-9). This PoC, implemented in a [Phat Contract](https://wiki.phala.network/en-us/general/phala-network/products/#phat-contract) demonstrates the following steps: +1. The user sends the *sourceToken* to the protocol. +2. The protocol XCM asset transfers this token amount to the *destinationChain*. +3. The protocol swaps *sourceToken* for *destinationToken* on the remote chain's Uniswap-like DEX. +4. The protocol transfers *destinationToken* from its escrow account to the user's wallet on *destinationChain*. + +#### Existing Code and Design Documents +Please check out the [main repo](https://github.com/kapilsinha/privadex). It contains some of the source code we have already written as well as design documents (in `README` files) for the incomplete items. + +### Ecosystem Fit + +#### Serving DEX users on every parachain +While Polkadot is designed for interoperability amongst chains, most XCM development efforts (e.g. X-Tokens/XTransfer pallets, bridges, remote execution) largely still serve developers, not lay end users. + +PrivaDEX is intended for DEX users on every Polkadot parachain. It enables users to conveniently trade cross-chain and efficiently trade intra-chain. + +#### Comparing to EVM DEX aggregators +There are *no* similar DEX aggregators in the Polkadot ecosystem. Other blockchains have DEX aggregators that generally fall under two categories: +1. Intra-chain DEX aggregator like 1Inch: these find optimal routes by consolidating data from multiple DEXes on a single chain. There is no cross-chain component. +2. Multi-chain DEX aggregator like Rango Exchange: these have poor (1) support for non-EVM chains, (2) UX, and (3) quality of routing solutions. PrivaDEX addresses these three shortcomings: + +(1) PrivaDEX has built-in Substrate and EVM compatibility and thus can uniquely integrate with any parachain (and associated XCMP channels). + +(2) PrivaDEX requires the user to sign just one transaction. Multi-chain aggregators like Rango require the user to sign a transaction each step of the way. This makes for a huge UX difference: users should be able to click a button and walk away, not need to stay on a webpage for minutes and sign multiple transactions along the way. + +(3) PrivaDEX smart order router logic involves splitting the route to optimize for price impact (which becomes a significant consideration where liquidity is relatively low). Rango never splits routes to optimize for price impact. Note that this is not a simple add-on feature because it is also a result of their requirement that a user sign every transaction - they would have to ask the user to sign 2-3x as many transactions to account for these split routes! + +## Team :busts_in_silhouette: + +### Team members + +- Kapil Sinha +- Ayan Bandyopadhyay +- Bradley Justice + +### Contact + +- **Contact Name:** Kapil Sinha +- **Contact Email:** ksinha1999@gmail.com +- **Website:** Coming soon! + +### Legal Structure + +- **Registered Address:** We do not have a registered address +- **Registered Legal Entity:** We do not have a registered legal entity + +### Team's experience + +Kapil, Ayan, and Bradley had earlier built [DealDex](https://drive.google.com/file/d/13JahtsT2jWUqRIOJDOFduMairfOZd3dD), an investing platform for Web3 angel syndicates. Before that, they had built [RTCanary](https://www.producthunt.com/products/rtcanary), a video conferencing analytics platform. + +Kapil developed trading systems for a large trading firm and later personally developed and ran systematic strategies on StellaSwap and BeamSwap. + +Ayan improved security and developed UI for Robinhood and later at CoinTracker. + +Bradley developed automation infrastructure, focusing on fault tolerance and failover scenarios, at Microsoft Power Automate. + +### Team Code Repos + +The main source code repo (check out the progress thus far!) is at +- https://github.com/kapilsinha/privadex + +Team GitHub accounts: +- https://github.com/kapilsinha +- https://github.com/Ayan-Bandyopadhyay +- https://github.com/bradjustice97 + +### Team LinkedIn Profiles +- https://www.linkedin.com/in/kapil-sinha/ +- https://www.linkedin.com/in/ayan-bandyopadhyay-9a45b1103/ +- https://www.linkedin.com/in/bradley-justice-568519195/ + + +## Development Status :open_book: + +### Market Research & Inspiration +Kapil personally felt the need for a user-friendly aggregator when he was systematically trading on Moonbeam's DEXes from August to September 2022. Scaling any strategy on a single venue was impossible. Low liquidity meant high price impact, and diminishing marginal returns meant high opportunity cost. Manually swapping tokens and bridging them from various UIs took too much time and manual involvement. + +Parity's Rae Deng summarized the need for a DeFi aggregator in Polkadot in [this Polkadot forum post](https://forum.polkadot.network/t/what-needs-to-happen-for-our-defi-ecosystem-asap/1092/10): + +>[There is a need for a] DeFi aggregator like 1inch or Matcha using XCM. Right now the liquidity is scattered on different parachains. It would be helpful to have a DeFi aggregator which can find the best route to swap assets by leveraging liquidity on different parachains. + +### Current Progress +We have developed a proof-of-concept [here](https://drive.google.com/file/d/1jmPsCUfRWBJX6oRYvmAUGISYzbz2U0-9). + +The work-in-progress source code and design docs (in `README` files) are in the [main repo](https://github.com/kapilsinha/privadex). We have made good progress on the price feed, chain metadata store, and network graph generation. Together, these components allow us to auto-generate a network graph of the ecosystem with real-time prices. + +You can find a snapshot of this token graph (comprising Polkadot, Moonbeam, and Astar; scraping data from StellaSwap, BeamSwap, and ArthSwap) that we auto-generated [here](https://raw.githubusercontent.com/kapilsinha/privadex/main/privadex/routing/generated_graph.svg) (raw data is [here](https://raw.githubusercontent.com/kapilsinha/privadex/main/privadex/routing/generated_graph.dot)). + +## Development Roadmap :nut_and_bolt: +We had started development in the first week of October, so we have made good headway towards achieving the below milestones. + +### Overview + +- **Total Estimated Duration:** 5.5 months (~2.5 more months) +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 55,000 USD + +### Milestone 1 — Network graph generator API +Note: This milestone is largely completed. You can find a sample output snapshot of a graph comprising Polkadot, Moonbeam, and Astar [here](https://raw.githubusercontent.com/kapilsinha/privadex/main/privadex/routing/generated_graph.svg) (raw data is [here](https://raw.githubusercontent.com/kapilsinha/privadex/main/privadex/routing/generated_graph.dot)). + +- **Estimated duration:** 1.5 months +- **FTE:** 2 +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can call the API to generate an execution plan. | +| **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. There will be a standalone example that calls the API and generates a graph dot file. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test the API delivered in this milestone. | +| 1. | Price feed for ArthSwap | We will create a GraphQL API to scrape prices from ArthSwap's constant product AMM contracts. | +| 2. | Price feed for StellaSwap | We will create a GraphQL API to scrape prices from StellaSwap's constant product AMM contracts. | +| 3. | Price feed for BeamSwap | We will create a GraphQL API to scrape prices from BeamSwap's constant product AMM contracts. | +| 4. | Rust GraphQL client | This Rust client will construct queries for the above GraphQL APIs and deserialize responses into Rust-native structs. | +| 5. | Chain metadata store | This Rust crate will contain bridge, chain, DEX, and token metadata for the Polkadot ecosystem necessary to construct a complete network graph. | +| 6. | Graph library | We will heavily leverage the existing Rust [graphlib](https://github.com/purpleprotocol/graphlib) library but make modifications to support no_std. | +| 7. | Network graph construction | This will combine GraphQL queries and the chain metadata store to create the graph using the above graph library. | + + +### Milestone 2 — Execution plan generator API +An *execution plan* is a series of steps (e.g. swap ASTR for DOT on Arthswap, transfer DOT to Polkadot relay, etc.) to convert sourceToken on sourceChain to destinationToken on destinationChain. + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **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** that explains how a user can call the API to generate an execution plan. | +| **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. There will be a standalone example that calls the API and generates an execution plan. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test the API delivered in this milestone. | +| 1. | Smart order router algorithm | The SOR will find the optimal path through the graph created in the previous milestone, outputting a `GraphSolution`. | +| 2. | GraphSolution to ExecutionPlan converter | This Rust crate will translate a `GraphSolution` into an `ExecutionPlan` e.g. convert directed graph edges [ARSW -> ASTR, ASTR -> DOT, DOT_Astar -> DOT_Polkadot] into abstract instructions that can be used to submit transactions and extrinsics later. | +| 3. | ExecutionPlan validator | This Rust module will check invariants in the outputted ExecutionPlan to ensure it is valid and executable. | + + +### Milestone 3 — Executor Module +The executor module is Phat Contract code that actualizes the above execution plan, submitting transactions and extrinsics to perform swaps, bridges, and transfers. + +#### FAQs on Phat Contract +What is Phat Contract? +* Phat Contract is a decentralized off-chain computation framework developed by Phala Network. Note that there is *zero* connection between Phat Contract and the Phala blockchain, as this framework is entirely off-chain. + +Why use Phat Contract? +* Phat Contract allows us to securely store our protocol's keys (both wallet secret keys and off-chain storage API keys) in the contract (via the Trusted Execution Environment). As a result, we can submit transactions/extrinsics from a decentralized and transparent computing environment instead of a centralized service. + +How can we evaluate Phat Contract? +* We will place all business logic in separate modules, and create a thin Phat Contract wrapper that ties the components together. That means that every logical component can be run from a standard computer because it will be normal Rust code (similar to Substrate blockchain code). In fact, one can even perform an end-to-end test (that moves and swaps real tokens) from a local environment since secret keys can be kept locally. + + +- **Estimated duration:** 1.5 months +- **FTE:** 2 +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can call the Phat Contract execute the next step of their cross-chain swap. | +| **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 generate the WASM code. Note: Phat Contract runs in a Trusted Execution Environment and local deployment is not well supported yet. We will provide instructions on how to run this component via the [Phat Contract UI](https://phat.phala.network). | +| 1. | Rust Ethereum interface utils | This Rust mod will provide helper utilities to construct Ethereum transactions and parse Ethereum transfers. | +| 2. | Rust Substrate interface utils | This Rust mod will provide helper utilities to wrap RPC calls (e.g. to query nonce, runtime version, block hash) and deserialize them into Rust-native structs. | +| 3. | Substrate extrinsic signature and construction utils | This Rust mod will handle the various chains' signature schemes (Sr25519 and ECDSA), and construct extrinsics using those signatures and payloads. This code will leverage components of [subxt](https://github.com/paritytech/subxt) but note that we cannot use it as-is because of limited memory constraints in a Phat Contract. This means that we will need to write our own low-level code to encode extrinsics correctly. | +| 4. | Phat Contract controller/driver | As the event driver that runs in the Phat Contract, this will have functions to process each supported `ExecutionStep` and create the appropriate transactions/extrinsics. It will also expose this `processStep` function to the caller. | + + +### Milestone 4 — Consolidated backend API and swap UI +The backend API ties together the above components and builds in a scheduler to handle multiple sequential steps, exposing REST functions that can be called from a browser. The swap UI provides a frontend for this API. + +- **Estimated duration:** 1.5 months +- **FTE:** 2 +- **Costs:** 15,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can use the API to execute their cross-chain swap. | +| **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 | N/A. The main deliverables are the UI and its REST backend (that connects to the Phat Contract, which cannot be run locally), so containerization provides little value. | +| **0e.** | Article | We will publish an **article**/workshop that explains how to DEX users on how they can use PrivaDEX to perform cross-chain swaps and intra-chain aggregated swaps. | +| 1. | S3 API for executor | Building on Phat Contract's S3 example code [here](https://github.com/christopherfkk/fat-contract-s3-sync), this S3 API will perform state management for the executor e.g. keeping track of the status of an ExecutionPlan. | +| 2. | Executor module scheduler | Leveraging Phat Contract's [rollup scheduler](https://medium.com/phala-network/phala-will-enter-its-1st-halving-period-phalaworld-unlimited-shell-mint-has-started-phala-ce6c6e3028b8) and the above S3 API, this scheduler will manage state and call the appropriate `processStep` function (from the previous milestone) for pending swaps. Note that Phat Contract inherently is stateless and because it requires wait times between block inclusion, it performs one step at a time. | +| 3. | QuoteGetter API | This API will be called by the UI to estimate a quote before the user requests a swap. It will construct the network graph and call the smart order router (as defined in the previous milestones), and estimate a quote based on the computed route. | +| 4. | SwapRequest API | This API will be called by the user via UI to transfer funds to the protocol and initiate the swap ExecutionPlan. | +| 5. | GetSupportedChainTokens API | This API will be called by the UI to generate a list of tokens (and chains) from/to which the user can swap. | +| 6. | Swap UI | This Uniswap-like UI will use the APIs defined in this milestone for its backend calls. It does not require a database but will be hosted by a cloud provider. The frontend will leverage existing code e.g. components from the [Uniswap interface](https://github.com/Uniswap/interface). | + + +## Future Plans + +We will manage a Discord channel to communicate directly with end users. Closer to the end of the MVP development, we will make announcements to prepare for our launch. + +Long-term, we intend PrivaDEX to be a cross-chain DeFi hub for Polkadot. We will continue to improve the product and develop new features (e.g. parallel processing of execution steps to decrease slippage) to improve trade execution. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Rob Habermeier recommended that we explore Web3 support and reach out to Parity Growth. Nicolas Arevalo advised me further to apply for a Web3 grant! + +We have applied for a grant from the Moonbeam Foundation that is more focused on providing value to the Moonbeam EVM ecosystem. diff --git a/applications/Profond.md b/applications/Profond.md new file mode 100644 index 00000000000..1ffc4d68a3a --- /dev/null +++ b/applications/Profond.md @@ -0,0 +1,158 @@ +# [Profond.ai](http://Profond.ai) - No Code Builder for artists and developers to build, validate, and scale their dApp. + +- **Team Name:** Profond AI, Corp. +- **Payment Address:** 0x92710b669eA59b348cfbe6dcA8682DAabfB5f06A (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + +### Overview + +[Profond.ai](http://profond.ai/) is web3 tools to help developers and creators to build, validate, and scale their dApps. We provide smart contract builder (NFT and token), analytic, and indexer. + +We’re focusing on emerging chain and we aim to onboard millions of developers by making it easier onboarding for users to create smart contracts. + +### Project Details + +We’re inspired by [Pagoda.co](http://Pagoda.co), no code builders in the Near Ecosystem. It provides: + +1. No Code Builder: Create smart contracts for Token and NFT +2. Indexer (coming soon): To help successful projects and enterprises scale their dApp. +3. Analytics (coming soon): Data analytics for smart contracts, covering volume, users, transactions, and gas fees. +4. API Analytics (coming soon): To get data from analytics. + +Currently, we’re building MVP for users to create NFT and Token. Analytics, API and Indexer is still under development. + +We’re planning to add more parachains from Polkadot and Kusama to our platform. Here’s our current MVP: [http://console.profond.ai/](http://console.profond.ai/) + +Create NFT Collection + +NFT Tools +NFT Tools, currently require users to manually upload the collection via NFT-Up, we’re working to make it drag&drop + +![Untitled (2)](https://user-images.githubusercontent.com/81077632/232679334-a4c46b51-14e5-4be9-8c56-99a4c32152b2.png) +Token/Coin tools. We’re looking at the example when we creating 1 million XOIN token (see “Coin Minting” section) + +Analytics +Example of smart contract analytic. In this image, we’re doing analytic on marketplace.paras.near. + +### Ecosystem Fit + +We aim to launch on Polkadot and Kusama, here’s what problem we’re trying to solve: + +- For creators, creating a smart contract for their NFTs and tokens is hard. Especially in relatively new WASM smart contracts like ink! . +- For UI developers, blockchain development is too complex. Furthermore, each chain has its own complexity. +- Limited tooling for Polkadot and Kusama ecosystem. +- For emerging chain, we help them create smart contract templates. + +## Team :busts_in_silhouette: + +### Team members + +- CEO & Founder: Adhiguna Mahendra +- Product Lead & Founder: Ekki Rinaldi (Ekki) +- Full-stack Developer & Founder: Rizky Irfianto (Irfi) +- Database Engineer & Founder: Bagas Prakasa +- Full-stack Developer: Ade Yusup +- Smart Contract Engineer: Amajid Sinar (Jedi) +- Business Development: Vincent Salaka + +### Contact + +- **Contact Name:** Ekki +- **Contact Email:** ekki@profond.ai +- **Website:** https://profond.ai + +### Legal Structure + +- **Registered Address:** 2810 North Church Street, Wilmington, Delaware 19802 +- **Registered Legal Entity:** Profond AI, Corp. + +### Team's experience + +Our founders we’re building the biggest NFT marketplace in the Near ecosystem (Paras NFT Marketplace) and recently integrated with Astar Network. As builder and part of NFT community, we understand what builders need (especially FE engineer) and for artist who want to launch their on NFT. Our team led by tech veteran who had experience working in Silicon Valley, Adhiguna Mahendra, with 20+ years of experience. + +We helped grow the NEAR NFT ecosystem by contributing to NFT with open-source projects such as NFT smart contract standard, marketplace smart contract, vesting smart contract, and so on as you can see on the project’s repo: [https://github.com/parasHQ/](https://github.com/parasHQ/) + +Here’s our recent works: + +Paras Launchpad: [https://launchpad.paras.id/](https://launchpad.paras.id/) - NFT Launchpad in Astar using ink! + +Arkana Raffler: [https://arkana.gg/](https://arkana.gg/) + +Pipapo Ticketing System: [https://pipapo.io/](https://pipapo.io/) + +### Team Code Repos + +- [https://github.com/emarai](https://github.com/emarai) +- [https://github.com/ekkirinaldi](https://github.com/orgs/profondHQ/people/ekkirinaldi) +- [https://github.com/bagasprakasa](https://github.com/bagasprakasa) +- [https://github.com/internnos](https://github.com/internnos) +- [https://github.com/adeyusupp](https://github.com/adeyusupp) + +### Team LinkedIn Profiles (if available) + +- [https://www.linkedin.com/in/adhigunamahendra/](https://www.linkedin.com/in/adhigunamahendra/) +- [https://www.linkedin.com/in/bagasprakasa/](https://www.linkedin.com/in/bagasprakasa/) +- [https://www.linkedin.com/in/irfianto/](https://www.linkedin.com/in/irfianto/) +- [https://www.linkedin.com/in/amajidsinar/](https://www.linkedin.com/in/amajidsinar/) +- [https://www.linkedin.com/in/ekkirinaldi/](https://www.linkedin.com/in/ekkirinaldi/) +- [https://www.linkedin.com/in/vincentsalaka/](https://www.linkedin.com/in/vincentsalaka/) +- [https://www.linkedin.com/in/adeyusupp/](https://www.linkedin.com/in/adeyusupp/) + +## Development Status :open_book: + +PoC → Here’s our current MVP [http://console.profond.ai/](http://console.profond.ai/) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** Duration of the whole project (e.g. 2 months) +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** $10.000 + +### Milestone 1 — No code smart contract builder + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 4,000 USD + +| Number | Deliverable | Specification | +| --- | --- | --- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide documentation page on how to create NFT (PSP34) and FT (PSP22) smart contract with our interface. API documentation for project settings will also be provided. | +| 0c. | Testing and Testing Guide | All functions will be covered with full integration test, testing guide will also be provided. | +| 0d. | Article | We will publish an article that explains the no code builder | +| 1. | No Code NFT Creation (ink!) | Allows users to create NFT collection smart contract (PSP34) using ink! in one of WASM supported Parachains. User will be able to login with Polkadot Wallet (SubWallet, polkadot.js, Talisman) and then deploy smart contract with provided code hash. The code hash will be uploaded using selected templates from OpenBrush PSP34 Smart contract. We are abstracting the technical details from users, users just need to upload NFT images, set metadata, and pay gas fee to deploy the smart contract. We will be using useInkathon for wallet and transaction, Next.Js for frontend framework, and OpenBrush for smart contract templates. | +| 2. | No Code Fungible Token Creation (ink!) | Allows users to create NFT collection smart contract (PSP34) using ink! in one of WASM supported Parachains. User will be able to login with Polkadot Wallet (SubWallet, polkadot.js, Talisman) and then deploy smart contract with provided code hash. The code hash will be uploaded using selected templates from OpenBrush PSP22 Smart contract. We are abstracting the technical details from users, users just need to set metadata and pay gas fee to deploy the smart contract. We will be using useInkathon for wallet and transaction, Next.Js for frontend framework, and OpenBrush for smart contract templates. | +| 3. | Project Management Module | Allows users to create more than one projects. We are using NestJS for backend framework. | +| 4. | Multichain Integration | Allows users to choose between Polkadot Parachains and Kusama | + +### Milestone 2 Example — Analytics and API + +- **Estimated Duration:** 1 month +- **FTE:** 2 +- **Costs:** 6,000 USD + +| Number | Deliverable | Specification | +| --- | --- | --- | +| 0a. | License | MIT | +| 0b. | Documentation | We will provide documentation page on how to create basic NFT collection (PSP34) using our no-code builder and creating a fungible token (PSP22). | +| 0c. | Testing and Testing Guide | All functions will be covered with full integration test, testing guide will also be provided. | +| 0d. | Article | We will publish an article that explains the analytics and API usage | +| 1. | Analytic Functionality | Add on-chain analytic for the smart contract. | +| 2. | REST API Service | API for users to get the data analytic. | + +## Future Plans + +Experimenting in business model. We have two kind of ideation we want to validate: + +1. Indexer service, providing RPC for dApp to cut their operational costs +2. Royalties enforcement for each NFT created. + +On top of that, we aim to onboard more emerging chains and big chains like Solana and Ethereum. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/QRUCIAL_DAO.md b/applications/QRUCIAL_DAO.md index eb0a05c8f24..b62a32f8c14 100644 --- a/applications/QRUCIAL_DAO.md +++ b/applications/QRUCIAL_DAO.md @@ -1,12 +1,11 @@ -# W3F Grant Proposal +# QRUCIAL DAO > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. > > See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. -- **Project Name:** QRUCIAL DAO -- **Team Name:** QRUCIAL OÜ -- **Payment Address:** BTC - bc1qysscajxdstqzpe3x9x4ftr3y6l5gelggtk8a8g +- **Team Name:** QRUCIAL DAO +- **Payment Address:** BTC - 32V2Qmk2xNVddNNvwxGPDhdsofLJr6Gcsa - **Level:** 2 > ⚠️ *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.* @@ -33,23 +32,26 @@ We are the first connecting defensive as well as offensive security tool executi - Core components include Substrate, QRUCIAL DAO runtime, pallets and the ExoGlue. - PoC can be found in the reference QRUCIAL DAO repository below. -- What your project is _not_ or will _not_ provide or implement +- What your project is *not* or will *not* provide or implement - We won't solve business questions here, though we think our idea fill fit into the Polkadot/Kusama ecosystem. - This project won't save all the smart contracts or render manual auditors/hackers useless. Quite the opposite, by providing proven execution, we want to provide work to the manual workers who verify and validate vulnerabilities. - Main programming languages to be used: Rust, Python and JavaScript (for frontend)

          - +

          #### What is ExoSys? + ExoSys is the system that schedules audit requests and handles ExoTool connections. It is implemented as a combination of a pallet and a daemon, running on the same system as the blockchain node. ExoSys is also responsible for issuing the Non-Transferrable NFTs and keeps a track record of audit hashes and meta data. #### What is ExoTool? + Selected set of security auditor tools, packaged and adapted to be executed by the request of ExoSys. #### What is AuditorRep? + Élő's assumption is that the performance of an auditor in each audit is a random variable following a normal distributed bell curve over time. An auditor might perform significantly better or worse from one audit to the next. Using Élő their mean skill level would remain the same. @@ -59,14 +61,16 @@ If additional vulnerabilities are found or false positives are removed, the cha The increase and decrease of every individual auditor is relative to the Élő score of the original auditor and the one re-auditing a project. High ranked auditor wins: + - few points are transferred from the low ranked auditor to the higher rated one. Low rated auditor wins: -- a lot of points are transferred from the higher rated auditor to the low rated one. + +- a lot of points are transferred from the higher rated auditor to the low rated one. #### What is the CCTF talent pool? -CCTF provides a proven track record of hackers solving challenges and based on their reputation, they are awarded as manual auditors in the QDAO ecosystem. +CCTF provides a proven track record of hackers solving challenges and based on their reputation, they are awarded as manual auditors in the QDAO ecosystem. ### Ecosystem Fit @@ -80,25 +84,23 @@ CCTF provides a proven track record of hackers solving challenges and based on t ### Team members - Web3 Architect: six / David Pethes - CTO of QRUCIAL, Founder of CCTF, Polkadot Head Ambassador of Eastern Europe -- Business Architect: ra33it0 / Sebastian Kraus - CEO of QRUCIAL, EFF member - Runtime Developer: Wigy / - Senior Rust developer, Ex-Parity substrate core developer -- Full-stack Developer: Silur / Ábrahám Endre - Researcher at Hungarian Academy of Sciences (MTA), Ex-Ethereum Foundation developer -- DevOps Engineer: knockoff / Nico Selby - R&D team manager at QRUCIAL +- Frontend Developer: kmildi / Ildiko Keleti - Senior Web3 Frontend developer ### Contact - **Contact Name:** six / David Pethes -- **Contact Email:** hello@qrucial.io +- **Contact Email:** six@cryptoctf.org - **Website:** qrucial.io ### Legal Structure - **Registered Address:** Harju maakond, Tallinn, Kesklinna linnaosa, Narva mnt 7-652, 10117 -- **Registered Legal Entity:** QRUCIAL OÜ, Registration number: 16357543 +- **Registered Legal Entity:** Crypto CTF OÜ, Registration number: 16156552 ### Team's experience -QRUCIAL OÜ is a web3 security company. +QRUCIAL is a web3 security DAO. This is the first time we apply for a grant. @@ -113,7 +115,6 @@ Silur is working at the Hungarian Academy of Sciences (MTA) as cryptographer, wa knockoff is linux system administrator and junior rust developer. - ### Team Code Repos - https://github.com/Qrucial/QRUCIAL-DAO @@ -139,7 +140,6 @@ We have started the development already, details can be found under this reposit The PoC is working, and we want to move forward in developing a live testnet version. - ## Development Roadmap :nut_and_bolt: ### Overview @@ -160,7 +160,7 @@ The PoC is working, and we want to move forward in developing a live testnet ver | 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 1. | Substrate runtime | The runtime config and compilable code for QRUCIAL DAO. | +| 1. | Substrate runtime | The runtime config and compilable code for QRUCIAL DAO. | | 2. | Substrate pallet: ExoSys | Core system that handles the extrinsics that request ExoTool execution. | | 3. | Substrate pallet: AuditorRep | Reputation system for the manual auditors who verify the output recorded by ExoSys. | | 4. | Substrate report storage | Includes the tools exogenous to the Substrate system, it is connected through the glue/proxy. | @@ -168,7 +168,7 @@ The PoC is working, and we want to move forward in developing a live testnet ver ### Milestone 2 — Implement Exogenous tooling and hardened node system -- **Estimated duration:** 2 months +- **Estimated duration:** 2 months (final delivery in 2023 June) - **FTE:** 0.7 FTE - **Costs:** 20,000 USD @@ -184,15 +184,12 @@ The PoC is working, and we want to move forward in developing a live testnet ver | 3. | ExoTool - CCA | Implement [Clippy](https://github.com/rust-lang/rust-clippy) and [Cargo Audit](https://docs.rs/cargo-audit/0.15.1/cargo_audit/) as an exotool package for ink!/WASM smart contract audits. | | 4. | ExoTool - Octopus | Implement [Octopus](https://github.com/pventuzelo/octopus) as an exotool for bytecodes (WASM and Solidity) | - ## Future Plans -- In the short term, we'd like to have the grant, so development goes faster. QRUCIAL as a company will keep funding the project until it becomes self-sustaining (meaning, the governance system keeps the DAO running on its own). +- In the short term, we'd like to have the grant, so development goes faster. QRUCIAL DAO keeps funding the project on its own. - CCTF (cryptoctf.org) is already a partner, helping to bring the best web3 hackers to the system. -- Elfz'n'Trollz is a marketing partner, so we don't just develop a DAO, but also make it usable and visually acceptable to all audiences. - After final milestone, we will start building a larger community for QRUCIAL DAO and improve our partnership with CCTF. - ## Additional Information :heavy_plus_sign: **How did you hear about the Grants Program?** Personal recommendation from Achim Schneider and Jonan. diff --git a/applications/QSTN.md b/applications/QSTN.md new file mode 100644 index 00000000000..7d045fb8e0d --- /dev/null +++ b/applications/QSTN.md @@ -0,0 +1,280 @@ +# QSTN + +- **Team Name:** QSTN +- **Payment Address:** ETH (USDC) - 0x7056A5Da7D269B31Eb2E54E5579e41ef283d7D2C +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + +### Overview + +- QSTN is a Web3 survey marketplace where businesses fund surveys, reward participants, and uphold user privacy through our data wallet-driven profiles. +- QSTN is a cutting-edge platform that combines AI-driven surveys with a secure data wallet. Our solution empowers users to earn digital rewards from surveys while maintaining privacy. We're revolutionizing data monetization in the digital age. + +At QSTN, we aim to revolutionize the data collection landscape by addressing key challenges faced by traditional survey platforms. We understand that user engagement is essential for successful data collection, which is why we offer a gamified experience to incentivize users and boost response rates. Through our platform, businesses can easily fund surveys using digital tokens or NFTs, streamlining payment processes and ensuring faster and more efficient transactions. + +One of the most significant concerns in data collection is data privacy and security. We prioritize user trust and confidence by providing our data wallet, Cubby, which allows users to maintain full control over their data. This secure environment ensures that users' personal information remains private, making them more willing to share valuable insights. Additionally, we equip businesses with AI-assisted survey creation and advanced data analytics tools, enabling them to derive meaningful insights from survey responses and make data-driven decisions. Our strategic partnerships with prominent blockchain projects like NEAR and Stellar further enhance our platform's capabilities and foster interoperability within the Web3 ecosystem. Through these solutions, we aim to create a compelling and user-centric data collection platform that empowers businesses and individuals alike. + +Demo: NEAR Protocol +https://drive.google.com/file/d/1P2NRbIx2VZhfIQ6FHKO5_YOyhFZHjbfW/view?usp=sharing + +- Building on this, we would like Polkadot to be the next blockchain we implement; allowing its users to answer questionnaires, earn DOT rewards and mint NFTs upon completion. + +The key to our platform is allowing users to monetize their personal information in a low gas, scalable environment and Polkadot meets both of these requirements. By supporting this initiative, the Web3 Foundation is investing in data infrastructure for the entire DOT ecosystem as well as creating a new “Play-to-Earn” model for data aggregation. + +For scope, QSTN can be broken down into two different user experiences: + +1. User experience - users create an account and then have the ability to complete 3 daily surveys in return for DOT tokens and NFTs +2. Business experience - businesses create an account and build their own survey, rewarding users for their participation in DOT tokens and NFTs + +We want to bring both experiences to the DOT ecosystem and allow businesses to fund, track and engage users via their own surveys with the assistance of AI. + +### Project Details + +### Ecosystem Fit + +- QSTN is an innovative Web3 survey platform that combines blockchain, gamification, and AI to revolutionize data collection. Businesses can easily fund surveys using digital tokens or NFTs, offering users enticing rewards for their participation. Our data wallet, Cubby, ensures users maintain full control over their data, ensuring privacy and security. + +To ensure this vision becomes a reality, we're harnessing the power of Safe's decentralized custody protocol and collective asset management platform. Users signing up on QSTN have their email addresses utilized to create individualized Safe vaults, powered by Web3 authentication. This integration enables users to complete surveys, earn zero-knowledge proofs, and subsequently claim their rewards directly within their EVM wallet. + +SAFE is a non-custodial solution by Consensys (https://safe.global/), it facilitates wallet creation utilizing email addresses. Currently, SAFE lacks support for Polkadot. Given this, we will enable users to interact directly with the pallet, easing the reward redemption process post-survey completion. The wallet we will use is Polkadot JS wallet. + +We aim to take advantage of the low gas, scalable environment offered on DOT to allow users to earn DOT, mint NFTs and transfer assets without exorbitant transactional fees. + +- Right now, our target audience can be broken down in the following groups: + +A. Agencies +* Marketing agencies + +*Target agencies to use for experiential campaigns + source to relevant clients + +B. Brands +* Airline +* Beauty brands +* Food delivery +* Record labels + +*Target customer experience, customer success and marketing team + +C. Educational institutions +* Colleges +* Universities + +*Target professors, teachers and researchers + +D. Web3 +* Analytics firms - Addressable, Chainalysis, Dune Analytics, Kaiko, Messari, Nansen, Pantera Capital, QuickNode, Solidus Labs +* DAOs +* Foundations +* NFT communities +* Exchanges + +*Target marketing, community outreach and developer support + +Here are some notable milestones we've achieved since inception: + +1. Secured a position in Outlier Venture's NEAR Base Camp, successfully closing our pre-seed round. +2. Developed a data wallet feature, now generating zero-knowledge proofs upon survey completion. +3. Integrated AI to assist businesses in crafting surveys and evaluating authenticity of responses through a "credibility" score. +4. Garnered preliminary interest from notable entities like NYU, Estée Lauder, and L'Oréal for potential test partnerships, in collaboration with the NEAR Foundation. +5. Were honored with acceptance into the Polkadot Blockchain Academy, although a visit was precluded due to visa constraints. + +- Our platform is able to act as a Web3 on-ramp because our design easily onboards novice, less experienced internet users. This is important because in our initial feedback, we learned a lot of internet users want to get into blockchain but do not have the capital, resources or know where to start. + +We were inspired by the Pi app, as well as Sweatcoin which are two “Play-to-Earn” models where users get rewarded for daily, micro tasks based on actions taken in-platform. + +QSTN builds on their concept by offering more exciting, engaging rewards, increasing the educational value behind our mission statement as well as creating a cohesive community for participants in our network (e.g. NFTs, metaverse). + +- There are currently no other projects similar to ours in the Substrate ecosystem. However, we do see a potential partnership with Ocean Protocol as we can sell and aggregate our data profiles within their primary market. + + - There are no other Web3 data market research portals but similar Web2 solutions include Google Form, Nielsen and Survey Monkey; the problem is these agencies do not have blockchain infrastructure currently in place. + +Our unique offering is the ability for Web2 users to answer questions, earn credits and buy NFTs within a "gas-less" environment but having the option to connect their wallet and mint once familiar with the technology. + +We spent the past year participating in over 7 accelerators to help drive the brand awareness within the Web3 space and ensure we become the "go-to" market research portal in blockchain. + + - There has been an increase in the “Play-to-Earn” model and a couple players who are making noise in the space would include Rabbit Hole (educational), NEAR Crowd (micro task), Axie Infinity (gaming), Pi (validation), and Sweat Coin (exercise). + +We see a market opportunity to use this model for data aggregation, gamifying marketing research and then selling this information to corporate sponsors who offer digital goods or discounts to our users. + +## Team :busts_in_silhouette: + +### Team members + +- Orrin Campbell, CEO: A marketing graduate from NYU, Orrin is an influential figure in the entertainment industry with millions of streams and followers. His media presence has been showcased on platforms like Dr. Phil, and his degree in marketing adds valuable insights to QSTN's growth strategy. + +Anibal Suriel, Chief Legal Officer: An NYU alum with a remarkable legal career, Anibal has worked for prestigious firms like KARM and R3. He possesses extensive legal expertise and is admitted to the bar in three states: New York, Florida, and Washington DC. + +Brigitte Pinewiski, Chief Partnership Officer & Web3 Physician: An author of "Wealthcare: Demystifying Web3 and the Rise of Personal Data Economies," Brigitte is also a Healthcare Advisor, Nex Cubed member, and TiE Board and Charter Member. Her expertise in Web3 and AI adds a unique perspective to the team, aligning with QSTN's focus on innovation in the healthcare realm. + +Carlos Guiamaraes, CTO & Lead Developer: Carlos brings a strong technical acumen to QSTN. As a skilled developer for over 15 years, his contributions are integral to the back-end architecture and tool integration, ensuring a seamless and efficient platform. + +Eduardo Gomes, Junior Developer: A promising talent, Eduardo contributes to QSTN's development efforts. With his skills and passion for identity, he adds value to the KYC and verification of users within the QSTN platform. + +Melanie Zhang, Creative Director: An NYU graduate with a keen eye for design and user experience, Melanie's artistic vision enriches the platform's aesthetics and fosters engagement with QSTN's users. + +Daniel Fadely, Financial Analyst: An NYU alum with a strong finance and investment background, Daniel's involvement in opening and running the investment club at NYU, along with experience in managing various portfolios, enhances the financial planning and analysis for QSTN. + +- Orrin Campbell – QSTN CEO +Twitter - https://twitter.com/realorrin +Instagram - https://instagram.com/realorrin +Linkedin - https://linkedin.com/in/realorrin +GitHub - https://github.com/@qstnus + +Anibal Suriel - QSTN CLO  +Linkedin - https://linkedin.com/in/anibal-suriel-esq + +Brigitte Piniewski - QSTN CPO +LinkedIn - https://www.linkedin.com/in/brigittepiniewski/ + +Carlos Guiamaraes – QSTN CTO & Lead Developer +GitHub - https://github.com/sekmet + +Eduardo Gomes - QSTN Junior Developer +GitHub - https://github.com/Eduardogbg + +Melanie Zhang - Creative Director +LinkedIn - https://www.linkedin.com/in/melanie-y-zhang/ + +Daniel Fadely - Financial Analyst +LinkedIn - https://www.linkedin.com/in/daniel-f-436377203/ + +### Contact + +- **Contact Name:** Orrin Vincent Campbell +- **Contact Email:** qstnus@gmail.com +- **Website:** https://qstn.us + +### Legal Structure + +- **Registered Address:** 67 Edgehill Drive, Wappingers Falls, New York, 12590, USA +- **Registered Legal Entity:** QSTN, LLC + +### Team's experience + +We incorporated QSTN in December of 2020 and immediately began seeking institutional guidance on how best to bring this product to market. Below is a chronological recount of incubators and hackathons we partook: + +1. QSTN graduates from the 1871 x BLK Tech Verizon incubator (first cohort) [2021] +https://1871.com/accelerator-blk-tech/ + +2. QSTN places 2nd and 4th in the Encode Club x Filecoin NFT Hackathon +https://medium.com/encode-club/nft-hack-finale-prizewinners-and-summary-a68be99f6c66 + +3. QSTN graduates from the Filecoin 2022 accelerator program +https://medium.com/encode-club/filecoin-accelerator-summary-94e30a571563 + +4. QSTN graduates from the Octopus Network x Huobi incubator program +https://medium.com/oct-network/spring-2022-octopus-accelerator-star-prize-winners-d884456ce248 + +5. QSTN is 1 of 5 teams to receive the official Star Prize +https://www.youtube.com/watch?v=72QqZ6MIxeo + +6. QSTN is featured on XFounders - +https://youtu.be/35Mv9rt5KHQ + +7. QSTN wins the Parsiq unicornization contest - +https://hub.parsiq.net/unicornization + +8. QSTN participates in the Mintbase Demo Day - +https://blog.mintbase.xyz/wrapping-up-mintbases-demo-day-f13fd192c8fc + +9. QSTN presents at the Mastercard x NEAR Demo Day - +https://youtu.be/TkfHLgsBxiE + +Orrin Campbell (Founder bio) - + +Orrin is a multi-faceted entrepreneur and entertainer, renowned for his innovative strides in the fintech and entertainment sectors. As the founder of QSTN, Orrin combines his passion for technology and entertainment to revolutionize data monetization through gamification. + +A recent graduate of NYU Stern School of Business, Orrin's journey is anything but ordinary. Before delving into fintech, he made waves as an entertainer, amassing millions of streams on Spotify. His charisma and talent led him to a highly publicized appearance on Dr. Phil's national television show, which catapulted him to social media stardom with 250,000 followers on TikTok, 15,000 on Instagram, and 40,000 on YouTube. + +Leveraging his newfound audience and background in entertainment, Orrin ventured into fintech with a vision to empower individuals to take control of their data. He founded QSTN, a groundbreaking platform that bridges the gap between data collection and user engagement through gamification and rewards. + +In just two years, Orrin’s leadership and innovation at QSTN have been recognized with wins in two blockchain competitions. He has also been an active participant in prestigious accelerators, including Verizon, GitHub, and NYU Future Labs. Orrin’s visionary approach has piqued the interest of giants like L'Oréal and Estée Lauder, with whom discussions are ongoing for potential collaborations. Additionally, NYU, his alma mater, is among the entities showing interest in QSTN. The platform has already garnered the attention of over 3,000 test users, marking a promising start. + +Orrin's combination of entertainment flair and technological acumen positions him as a trailblazer in the fintech space. Through QSTN, he is not just transforming data collection but reshaping the very fabric of user engagement and empowerment in the digital age. + +Dr. Phil episode - +https://www.youtube.com/watch?v=ReRddYVYfHU + +Press links - +https://vman.com/article/orrin-discusses-indie-rap-persona/ +https://lyricallemonade.com/p/meet-orrin-the-cyborg-rapper-sent-from-2050-to-save-us-all + +Socials - +https://tiktok.com/@realorrin (250,000 followers) +https://instagram.com/realorrin (18,000 followers) +https://youtube.com/c/realorrin (41,000 followers) + +### Team Code Repos + +- https://github.com/qstnus +- [https://github.com/qstn-ansr ](https://github.com/orgs/QSTN-US/repositories) +- [https://github.com/shadow111 ](https://github.com/sekmet) + +Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. + +- [https://github.com/shadow111](https://github.com/sekmet) + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/realorrin +- https://www.linkedin.com/in/anibal-suriel-esq/ +- https://www.linkedin.com/in/phillip-coleman-791b1475/ + +## Development Status :open_book: + +- Here is a link to the proposed functionality - https://drive.google.com/drive/folders/1AlOA2H8PE9RWnuXsSxvrBszCOVxkclrE?usp=sharing +- Here are links relevant to the problem - Article 1: https://www.npr.org/2021/02/25/971460327/tiktok-to-pay-92-million-to-settle-class-action-suit-over-theft-of-personal-data +Article 2: https://www.reuters.com/technology/metas-facebook-pay-90-million-settle-privacy-lawsuit-over-user-tracking-2022-02-15/ +Article 3: https://news.bloomberglaw.com/litigation/google-plus-7-5-million-privacy-settlement-gets-final-nod +- Here is a link to the QSTN Medium page where we post updates on data, De-Fi and NFTs - https://medium.com/@qstnus, stay up-to-date on our Twitter account - https://twitter.com/qstnus +- Here is a link to the conversation QSTN founder had with Neil deGrasse Tyson about data rights: https://youtu.be/ImdmYU6ykCo?t=1568 +- Please reference these two presentations for early iterations on the NEAR Protocol blockchain - Video 1: https://youtu.be/XnHjM4lQiZM, Video 2: https://youtu.be/dn49lQPibwU, + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 15 months +- **Full-Time Equivalent (FTE):** 8 employees (4 developers, 3 designers, 1 blockchain architect [Orrin]) +- **Total Costs:** 10,000 USD + +### Milestone 1 Example — Implement Substrate Modules + +- **Estimated duration:** 15 months +- **FTE:** 8 employees +- **Costs:** 10,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Open Source | We will open source the survey pallet since the other implementations are publicly available +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can generate a Polkadot.JS wallet during on boarding, connect this wallet to our web application, mint and/or transfer NFTs from our marketplace to their specified DOT wallet and save their "survey ID" on a local substrate chain as immutable proof of completion | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish a Medium article that documents our transition to Polkadot and details how users of QSTN can connect their DOT wallet to our application, mint & transfer purchased media onto the DOT blockchain as well as save their survey ID on-chain on a local substrate chain. +| 1. | Survey pallet | We will create a Substrate module that will allow users to complete a survey, earn a zero knowledge proof upon completion and then connect their Polkadot JS wallet in order to withdraw the pre-defined reward amount by interacting with the pallet. +| 2. | Survey pallet | We will create a Substrate module that will allow business to create a survey and then connect their Polkadot JS wallet in order to fund the pallet for respondents. +| 3. | Survey pallet UI | We will create a new UI for DOT users to be able to connect their Polkadot JS wallet, interact with the pallet to withdraw or fund survey rewards and mint their respective NFT media onto a local substrate chain. +| 4. | Substrate chain | The survey pallet of our custom chain will interact in such a way to allow users to connect their DOT wallet to our application, withdraw DOT and then mint media on a local substrate chain [1.] and these transactions take place within our new UI [3.] with proof recorded by our ZKP [5] after being funded by the business [2] and recorded in the data wallet [6] +| 5. | ZKP Proof Generation | We will create an API for the Cubby data wallet to generate zero knowledge proofs upon survey completion on the Substrate chain - this ZKP will be the "receipt" to verify users are eligible to connect their wallet and withdraw rewards from a particular survey contract. +| 6. | Data Wallet | We will open source our data wallet which is an authorizathion layer within QSTN allowing users to interact and generate zero knowledge proofs upon survey completion on DOT - this wallet interacts with the pallets deployed by our local substrate node through our API. + +... + +## Future Plans + +- As QSTN, our major product milestones for the next 6 months include: +1. Developing the Cubby Data Wallet, which will replace user profiles, enabling users to authorize data requests directly from a Chrome extension wallet. This feature enhances user control over their data and streamlines the authorization process. +2. Creating the Cubby File Storing Platform, a decentralized storage solution powered by Filecoin. Users and businesses can securely store their files, with the owner holding the only decryption key, ensuring privacy and exclusive access. +3. Collaborating with NYU, L'Oréal, and Estée Lauder to test and refine our platform by incentivizing their respective communities, helping us gather valuable insights and optimize our offerings. +4. Expanding our clientele beyond web3 startups to include larger legacy brands and marketing agencies. Our goal is to establish QSTN as the "go-to" self-service marketing tool for a diverse range of businesses seeking innovative and effective solutions. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** Web3 Foundation Website + +Here you can also add any additional information that you think is relevant to this application but isn't part of it already, such as: + +- Please request a private invite to our repo ([https://github.com/qstn-ansr](https://github.com/QSTN-US) for our existing prototype on NEAR Protocol +- If there are any other teams who have already contributed (financially) to the project. +- NEAR Foundation (grants program) diff --git a/applications/RainbowDAO Protocol ink! Phase 1.md b/applications/RainbowDAO Protocol ink Phase 1.md similarity index 99% rename from applications/RainbowDAO Protocol ink! Phase 1.md rename to applications/RainbowDAO Protocol ink Phase 1.md index 839da170a90..b0561630cec 100644 --- a/applications/RainbowDAO Protocol ink! Phase 1.md +++ b/applications/RainbowDAO Protocol ink Phase 1.md @@ -1,8 +1,5 @@ -# W3F Grant Proposal +# RainbowDAO Protocol ink! Phase 1 - - -- **Project Name:** RainbowDAO Protocol ink! Phase 1 - **Team Name:** Rainbowcity Foundation - **Payment Address:** 0xC2dA4D5813978BbC43d81e905dE6C98767526EdF (DAI) - **[Level]** 2 diff --git a/applications/RareLink.md b/applications/RareLink.md index 4375f026385..87d3e050a10 100644 --- a/applications/RareLink.md +++ b/applications/RareLink.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# RareLink Protocol -* **Project:** RareLink Protocol * **Proposer:** 0x522359 * **Payment Address:** 3Ah1QWfs9oEPdhRDYkWPSJYf5yKa7NLcSF * **Status:** [Terminated](https://github.com/w3f/Open-Grants-Program/pull/86#issuecomment-874241559) diff --git a/applications/RedStone Network.md b/applications/RedStone Network.md new file mode 100644 index 00000000000..8731b5d6ab4 --- /dev/null +++ b/applications/RedStone Network.md @@ -0,0 +1,159 @@ +# Redstone Network + +- **Team Name:** Redstone Network +- **Payment Address:** 0x24cfc36f699dacc5cb652630ddd894a8df658233 (Ethereum ERC20 USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/1093#issuecomment-1624203004) + +## Project Overview :page_facing_up: + +### Overview + +We are sincerely requesting a funding grant from the web3 Foundation to build a transaction firewall that will function as a last resort security barrier when user asset protection solutions fail. There have been several serious security incidents recently, including major asset losses due to the theft of private keys on the harmony and Ronin bridges. In the blockchain world, having a mnemonic or private key for an account is equivalent to getting ownership of that address; when a hacker obtains a user's mnemonic or private key, he or she is able to take all the assets in a short period of time without any problem, a situation that obviously should not exist all the time. When this problem is not solved or alleviated, the Web3 world is full of uneasiness and suspicion, and this situation will make it difficult for the Web3 world to gain larger scale support and popularity. + +The Redstone Network is a network of trigger circuits where users combine and arrange simple atomic trigger components according to certain rules and processes to eventually implement a series of automated operational circuits. We propose transaction firewall middleware that can function between any blockchain network, regardless of the cross-chain mechanism and network topology used to execute asset transfers, and regardless of the type of assets traded, we will construct a firewall of different security levels for users. With the help of triggers and machine learning technologies, we will provide users with passive defense and proactive alerting capabilities. + +We will work with parallel chains in Polkadot/Kusama to build and deploy the firewall function to enable a higher level of security for parallel chain asset interactions within the ecosystem; in addition, we can work with project parties or wallets in other ecosystems to provide them with this unique defense mechanism, ultimately reducing the risk of asset security across the Web3 world. + +### Project Details + +For the transaction firewall functionality, Redstone Network will build a set of on-chain/off-chain trigger components and their implementations. In general, users will not be aware of the firewall's operation, and the firewall will truthfully notify users of potential security risks when there are triggered alarms on the chain. + +#### Passive defense and active alarms + +- We build a series of stateless atomic trigger components, including on-chain triggers (quantity trigger, time trigger, price trigger), off-chain triggers (mail trigger, discord trigger, slack trigger) and off-chain message interaction components, which are responsible for actively obtaining external information or pushing messages to a specified server.; + +- Analyze transaction characteristics and behavior, design transaction protocol analyze the transaction characteristics and behavior, design the transaction protocol, check whether the basic information and check information of the transaction match through protocol parsing, and initially determine the validity of the transaction; +- according to the trigger and the transaction protocol, with the idea of social recovery and multiple signatures, formulate different security level trigger policies for users, including power grabbing mechanism, freezing mechanism and alarm mechanism. + +#### Intelligent termination of transactions with evil address monitoring + +The user-configured security scheme can effectively defend against known security problems, but not against unknown or unconfigured behaviors. By analyzing the transaction data recorded in the database under the chain, the transactions are analyzed according to the dimensions of transaction time, transaction frequency, transaction address, transaction direction, and transaction amount, and if the transaction behavior is different from the daily behavior, the meltdown mechanism will be triggered and alarmed; receiving the supervision instruction from a chain, the address that is doing evil and the derived address will be dynamically analyzed and the transaction meltdown mechanism will be triggered. + +For the application scenario of transaction firewall, it is mainly divided into token assets and NFT assets. Users can choose the type of asset that needs to be configured with the firewall, either for a certain token, or to protect the account that issues NFT assets. + +In addition, the transaction firewall feature is not dependent on any application, any architecture and any address type restrictions, making it flexible to handle a variety of new attack methods that are known or have not yet emerged in the future, as it aims to study the security of A to B transfers. + +**Technology stack** + +- Rust: Develop on-chain trigger/defense/alert modules +- Go/Python: Develop off-chain analysis/trace/alarm modules + +### Ecosystem Fit + +This project will be developed, deployed and run based on the Substrate framework. Unlike other trigger projects, with the advanced features of OCW, we are able to provide users with an advanced on-chain alert push mechanism, which will help shorten the time for users to get critical information. At the same time, rooted in Polkadot/Kasuma ecology, as a parallel chain, the trigger interface on it will provide additional application features for all parallel chains, and with the help of relay chains, it can facilitate unique transaction defense capabilities for other parachains. We note that we are entering a completely new area that will provide an unprecedented protection experience for the blockchain space once our project is in actual operation. + +## Team :busts_in_silhouette: + +### Team members + +- Bin Guo +- Li Smith +- yiwei Shi +- Leon + +### Contact + +- **Contact Name:** Bin Guo +- **Contact Email:** bin.guo@deeper.network + +### Legal Structure + +(we are in the process of registering the legal entity) + +- **Registered Address:** N/A +- **Registered Legal Entity:** N/A + +### Team's experience + +**Bin Guo** + +- Over 9 years of experience in software development and project management, engaged in work related to blockchain and big data, and worked in a core research institution of State Grid (Fortune 500). +- Polkadot senior ambassador, Substrate Evangelist, and early participants in the Polkadot ecosystem. +- Github: https://github.com/AmadeusGB +- Email: amadeusgb123@gmail.com + +**Smith Li** + +- Over 9 years of working experience in various aspects of computer programming. +- Worked in the blockchain industry for 3+ years, a blockchain development engineer, familiar with polkadot, bitshares, fabric, etc. +- Hackathon winner as a team tech leader: Winners of Polkadot Hackathon 2022. +- github: https://github.com/baidang201 + +**yiwei Shi** + +- Art and management background, worked for Hearst, MSN, responsible for market and product, more than one year of blockchain development experience, familiar with computer science, cryptography and different economic mechanisms, good at Go and Rust development。Hackathon winner as a team member: Winners of Polkadot Hackathon 2022 +- Github : https://github.com/shiyivei +- Email : shiyivei@outlook.com + +**leon** + +- Over 7 years of working experience in web development experience ande more than one year of blockchain development experience, familiar with FrontEnd, good at Js,Ts and Rust development.Hackathon winner as a team member: Winners of Polkadot Hackathon 2022 +- github: https://github.com/walle233 + +### Team Code Repos + +We have forked substrate-template repository code to implement on-chain triggers (quantity triggers, time triggers, price triggers) and off-chain triggers (email triggers, slack triggers) with the help of decentralized off-chain communication components, in addition, we have implemented a simple oracle machine。 + +- [difttt-node](https://github.com/difttt/difttt-node) +- [evm-proxy](https://github.com/difttt/evm-proxy) +- [slack-notify](https://github.com/difttt/slack-notify) +- [oracle_price](https://github.com/difttt/oracle_price) +- [frontend](https://github.com/difttt/frontend) + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2 FTE +- **Total Costs:** 20000 USD + +### Milestone 1 Example — Multiple passive defense mechanisms, as well as on-chain and off-chain alerting mechanisms + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 8,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide **inline documentation** for the code and a **tutorial** for users on how to configure the in-chain passive defense step, which will show how the new functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article** to explain the concept, design and implementation of the design in Grant and how to use these features in the blockchain) +| 1. | Passive_Defense Pallet | We will provide users with stateless and application-independent protective features, and this module will be implemented through Substrate Pallet:
          **transaction limit configuration**: configure in advance the limit of transferring a transaction amount and limit the frequency of transactions within a specified time; protect users from suffering significant losses for a short period of time when their private keys are stolen.
          **Freezing configuration**: advance configuration of freezing transaction time, freezing transaction type, and whether the freezing command can be withdrawn; when the user realizes that the private key has been stolen, the freezing operation will be triggered immediately to help the user further reduce losses.
          **Capture account authority configuration**: configure in advance N friend addresses and M for friend operations to take effect; when the user realizes the private key has been stolen, let the account freeze first and contact their friends as soon as possible. When more than M friends vote to pass, the authority of the stolen account will be taken over and any transaction will be executed only after N friends vote. This way even if the hacker steals the private key, he will not be able to transfer money effectively. | +| 2. | Active_Alarming Pallet | We will provide users with on-chain and off-chain alerting functions. This module will be implemented through Substrate Pallet:
          **On-chain alarm configuration**: Any transaction that exceeds the limit will send an alarm event; for example, the user can configure that when N transactions exceeding the limit amount occur within a period of time, an off-chain alarm notification will be triggered; the user can configure, a period of Within a certain time, different times will trigger different alarm methods.
          **Off-chain triggering alarms**: Provide users with three off-chain notification methods: Mail, Slack, and Discord. For example, general alarms are sent to Mail, important alarms are sent to Slack, and critical alarms are sent to Discord to achieve hierarchical management of alarms. | + + +### Milestone 2 Example — Intelligent meltdown mechanism, including abnormal trading meltdown, evil trading meltdown + +- **Estimated Duration:** 2 month +- **FTE:** 2 +- **Costs:** 12,000 USD + + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | GPLv3 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article** explaining the concept, design and implementation of smart meltdowns and how to use these features in the blockchain) +| 1. | Analyzer Module | We will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language：
          Users can choose whether to enable the off-chain transaction analysis function. The module records and analyzes user transaction characteristics based on a counter, and uploads to the blockchain when abnormal results emerge from the analysis. When a potentially abnormal transaction occurs, the user can choose, based on advance configuration, whether the module simply alerts when an abnormal transaction is reported, or freezes the account until the user comes to deal with the problem on their own. In this case, the hacker does not trigger any on-chain restrictions, only the off-chain transaction analysis detects the anomaly | +| 2. | Tracker Module | We will provide users with off-chain transaction analysis functionality, and this module will be implemented via the Go/Python programming language.
          This module implements the function of tracking the transaction records of a certain address at a certain time period, helping users to assist in analyzing the loss of the current address from the hacking attack, as well as analyzing the chain through which the hacker transferred the funds. | + +## Future Plans + +Conceptualizing the application with the trigger concept, implementing the transaction firewall first, and refining our design based on user feedback. +Implementation steps. + +- develop on-chain/off-chain triggers for firewall requirements. +- refining the firewall design based on user feedback. +- implementing cross-chain transactions and providing transaction protection for cross-chain links. +- configure different levels of defense strategies based on implementation experience. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +How did you hear about the Grants Program? We heard about the Grants Program from the Web 3 Foundation Website, as well as personal recommendations from Polkadot community members. diff --git a/applications/RegionX.md b/applications/RegionX.md new file mode 100644 index 00000000000..93efb5d3a7c --- /dev/null +++ b/applications/RegionX.md @@ -0,0 +1,281 @@ +# RegionX + +- **Team Name:** RegionX +- **Payment Address:** 0x1e86CD18E4443B5f57b0133077954Cd84896964d (USDC) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +### Overview + +Please provide the following: + +- This project is named RegionX, with 'X' representing 'exchange,' as the project serves as a Region exchange. +- RegionX is a marketplace and a set of tools for Coretime manipulation and data tracking, with the goal of making development on Polkadot faster, easier, more flexible, and, as an end result, cheaper. +- RegionX is a project that builds upon the ideas presented in the Agile Coretime RFC. The project will be developed under the assumption that the functionality described in the RFC will be implemented within the Polkadot/Kusama ecosystem. + Given that the `pallet-broker` already exists, we will have the capability to undertake all the development outlined in this proposal. +- Creating robust tooling and a market for Coretime can have a significant impact on the development that takes place on Polkadot. It will enable experiments and small personal projects to be deployed to Polkadot with minimal effort and cost. + +### Project Details + +This project, in its final phase, will have four cohesive components. These components are the following: +1. Coretime UI +2. Coretime Market +3. Data Analytics +4. Development Hub + +This proposal exclusively addresses the first two components, while information regarding the remaining components is available in the 'Future Plans' section below. + +The following sections describe only the components that will be developed for this grant. + +#### Coretime UI + +Considering that the entire project is built upon the ideas presented in the Agile Coretime RFC, users must be able to perform actions on their Coretime using RegionX. For this reason, we will provide the Coretime UI, which will simplify the management of regions. The following is a list of components we intend to incorporate into RegionX. + +- **Regions Dashboard** will serve as a central hub for users, allowing them to browse all of the regions they own. The regions will be presented as UI card components containing all relevant metadata and actions that users can perform on their region. + +

          + +

          + +- **Partitioning UI** will offer users a convenient method for splitting their region. The UI will visually represent the region as a timeline, highlighting all potential pivotal points available for partitioning. + + The Partitioning UI visualizes the region as a timeline and divides it into the selected TIME UNIT. This allows the user to easily determine the pivot point. + +

          + +

          + +- **Interlacing UI** will also allow users to easily interlace the region they own. The user will have the option to specify the region core mask as a fraction. + +

          + +

          + +- **Naming Regions & Tasks**: Users will have the option to assign names to their regions and tasks, making it simple to differentiate them. + +- **Assignment UI** will make it straightforward for users to allocate a task to their owned regions. The UI will display a dropdown menu containing all the tasks that the user has published to the relay chain, simplifying the selection process. + +

          + +

          + +- **Transfer** UI will offer a straightforward modal for users to perform transfers. + +

          + +

          + +#### Secondary Market + +Coretime is a resource that goes to waste if not utilized during its intended time. When you purchase a core for a month, it means you can use a maximum of one core at any given moment during that specific time period. If the core is not utilized, the Coretime is essentially squandered. + +After buying Coretime during the bulk period, one may realize that the purchased Coretime is either too much or too little for the intended use. The secondary market assists these individuals and teams in rectifying their mistakes by enabling them to sell or buy more Coretime. + +Coretime can be partitioned and interlaced, meaning most of the Coretime on sale will hardly be the same. For this reason, we are going to utilize the order book model. + +The seller will need to specify the price for the entire region, and based on that, the contract will calculate the price of one bit, which is equivalent to 1/80th of the price of the entire region. + +This bit-based valuation means that the total value of the Coretime owned by the seller will decrease every time the smallest computation unit is not used. From here, we can conclude that the price of the region on sale is dynamic. + +**The steps of selling and buying Coretime:** + +1. A user decides to sell one of their regions. + - The user defines the price that they intend to sell the region for. + - The contract calculates the price per bit. +2. Another user decides to buy some Coretime. + - They are browsing the market and have decided they want to buy a specific region. + - The user will have to pay the price for the region; however, this won't be the price of the entire region. The price will be defined by `remaining_smallest_units * price_per_unit`. +3. The user pays the price, the seller receives the paid amount, and the buyer receives the region. + +If a user doesn't want to buy the entire region but only a part of it, the buyer will need to specify which parts of the region they want and provide the steps to create a region with the properties they desire. This way, the user pays only for the portion of the region they wish to acquire. +We refer to this feature as **Region Derivation**. It will give buyers more options when purchasing Coretime, making it easier to meet their specific needs. This feature is not implemented as part of this milestone, but is part of our future plans. + +**Defining the price of Coretime** + +The price of Coretime will be highly influenced by supply and demand. Since we are constructing a market with an NFT order book model, users will have the authority to establish the price of the Coretime they intend to sell. + +Depending on whether the seller owns an entire core, only partitioned parts, or has it interlaced, the selling price of the Coretime will be affected. + +As mentioned earlier, we will determine the pricing of a region at a bit level. This approach proves particularly useful because it allows us to establish a pricing structure that decreases when Coretime is wasted. + +In situations where the buyer's instructions involve partitioning the region and performing interlacing on the partitioned region, we will determine the price based on the bit price of the resulting partitioned region. + +This approach allows us to easily calculate the price of the region the buyer intends to purchase, even in situations where the buyer requires multiple instructions to be executed on the region. + +**Formula to calculate the price when partitioning:** +`price = bit_price * pivot_defined_as_bit` + +**Formula to calculate the price when interlacing:** +`price = bit_price * active_bits` + +**Market Architecture** + +The Coretime marketplace can be implemented in four different ways, which include: + +1. Ink! smart contract +2. Solidity smart contract +3. Actor (Not yet implemented in Polkadot/Kusama) +4. Parachain + +From these options, we've selected the Ink! smart contract as our initial approach. As the project evolves, we anticipate transitioning to either an actor or a separate parachain to access greater possibilities to improve our services. + +**Implementation Requirements** + +We came up with an implementation design that makes it possible to develop the market as an ink! smart contract located on a contracts parachain in the Polkadot/Kusama ecosystem. +Our solution has very minimal and reasonable assumptions required to make this possible. + +Our sole assumption is that the concepts outlined in the Agile Coretime RFC are implemented in Polkadot/Kusama. We do not have any specific assumptions concerning the XCM configuration on the Coretime parachain to make this work. We only require that the Coretime parachain allows basic reserve transfers. + +**Region NFT Contract** + +To create a marketplace on a contracts parachain, we'll need an NFT region contract. We'll use the [Openbrush](https://openbrush.brushfam.io/) psp34 contract as a starting point for the code we develop. + +**Coretime Market UI** + +This section outlines the design of the Coretime market developed as part of this proposal. If additional relevant data is identified, we will expand upon the design. + +- The main market dashboard allows users to browse and filter, making it easier for them to find the region they are looking for. + + Users will have the flexibility to choose a time unit for inputting values, which will serve as the basis for region filtering. The maximum time unit available will be a day, allowing users to input values using a calendar input field. For other durations, users can simply provide numeric input in a designated field. + + The Core ownership field will be represented as a percentage range of the total Coretime ownership that the region has on a specific core. + +

          + +

          + +- The UI for performing cross-chain region transfers which will be utilized when transferring regions between the Coretime chain and the smart contract chain where RegionX is deployed, or vice versa. +

          + +

          + +- The UI for selling regions will become accessible to users once they choose one of their regions from the Region Dashboard. Any region listed for sale must be located on the smart contract parachain where RegionX is situated. In situations where the region is on the Coretime chain, users should first utilize the Cross-Chain UI for transferring the region. +

          + +

          + +### Ecosystem Fit + +RegionX will offer a Coretime market and a suite of tools, making it easy for teams to develop their projects on Polkadot or Kusama. This project will empower smaller teams by providing flexible options to purchase regions from the market. + +The xcRegion and Coretime market contracts are designed for use by future teams interested in developing Coretime-related projects. + +[Lastic](https://github.com/w3f/Grants-Program/pull/2008) is a project in the Polkadot ecosystem with similar goals to ours. However, we have already defined many of our future ideas, which they have not yet mentioned implementing into their project. We have also developed a feasible solution for creating a flexible Coretime market with a dynamic pricing model. +Given that the contracts developed as part of this grant are intended for use by many future projects, we would like Lastic to consider utilizing these contracts. As briefly mentioned in the _Future Plans_ section, we are also in the process of designing an economic model to incentivize the use of the same Coretime market. We believe this can foster healthy competition. + +## Team :busts_in_silhouette: + +### Team members + +- Sergej Sakac +- Oliver Lim + +### Contact + +- **Contact Name:** Sergej Sakac +- **Contact Email:** sakacszergej@gmail.com +- **Website:** https://regionx.tech + +### Legal Structure + +- **Registered Address:** Kanalska 7 Novi Sad Serbia +- **Registered Legal Entity:** MASTER UNION LLC. + +### Team's experience + +Sergej is a member of the Polkadot Fellowship. He has been an external core contributor on substrate and polkadot for more than a year now. Sergej is also a recent Engineering alumni of the Polkadot Blockchain Academy (PBA) held in Berkeley. + +Sergej has previously worked on a project that applied for a W3F. The details of the project can be found [here](https://github.com/Szegoo/Grants-Program/blob/42b031052c16670685c65a409d91779d0069903a/applications/Dotflow.md). + +Oliver is a full stack blockchain developer who was involved in 3 projects granted by the Web3 Foundation. He worked with Sergej on [Dotflow](https://github.com/thedotflow). + +Some of the past projects Oliver has worked on are [fs-dapp](https://github.com/fair-squares/fs-dapp), [imbue-frontend](https://github.com/imbuenetwork/imbue-frontend), [dotflow](https://github.com/TheDotflow/dotflow-ui) + +### Team Code Repos + +Github organization: https://github.com/RegionX-Labs + +Github profiles of team mebers: + +- https://github.com/Szegoo +- https://github.com/cuteolaf + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/sergej-sakac-334a47252 +- https://www.linkedin.com/in/cuteolaf + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 4 months +- **FTE:** 2 +- **Total Costs:** 30,000 USD + +### Milestone 1 - Coretime UI & xcRegions + +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 12,000 USD + +| Number | Deliverable | Specification | +| ------: | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | We will create documentation that thoroughly explains all aspects of the UI. Our goal is to design the UI to be as intuitive as possible, so users require minimal familiarization with the project. | +| **0c.** | Testing and Testing Guide | All interactions with the Coretime parachain will undergo comprehensive testing to guarantee a seamless experience for users when using the RegionX UI. We will be running a local Zombienet network to simulate the existence of a Coretime parachain. | +| **0d.** | Docker | We will provide a Dockerfile that will set up and run the RegionX Coretime UI. | +| 0e. | Article | We'll compose a Medium article to explain the UI abstractions we've introduced around Coretime, offering insights into the capabilities achievable through the utilization of the Coretime UI. | +| 1. | Mock Coretime Parachain runtime | We will establish a parachain dedicated to testing the Coretime abstractions and all future milestones. Essentially, this involves creating a parachain runtime that implements the `pallet-broker`. This parachain will simulate the Coretime chain. | +| 2. | Simulated Local Network | Using the mock Coretime parachain, we will create a local Zombienet network consisting of a relay chain, Coretime chain, and a smart contract chain for the Coretime market. | +| 3. | Coretime UI | We will implement all the sections and components described in the _Coretime UI_ section above. To summarize, this will consist of the following components: region dashboard, partitioning UI, interlacing UI, naming regions & tasks components, assignment UI and transfer UI | +| 4. | Cross-chain Regions | As described in the previous sections, we will create an ink! smart contract that will be representing regions on the contracts parachain where we choose to deploy RegionX. This essentially means that users will have the capability to transfer their regions from the Coretime chain to another parachain. This NFT contract will be expanded to include the option for the region owner to initially set the region's end. The contract will perform certain sanity checks, although it's important to note that the accuracy of this information is not guaranteed. The UI client will be responsible for ensuring the correctness of this information when querying the region. | +| 5. | xcRegion developer documentation | We will create documentation to explain how to easily integrate the xcRegion contract developed in this milestone. Our goal is to enable many teams in the future to integrate the contracts that are developed as part of this proposal. | + +### Milestone 2 - xcRegions UI & Coretime market contract + +- **Estimated duration:** 1.5 month +- **FTE:** 2 +- **Costs:** 18,000 USD + +| Number | Deliverable | Specification | +| ------: | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **0a.** | License | GPLv3 | +| **0b.** | Documentation | The ink! smart contract will be well-written and documented. We will also create documentation that thoroughly explains all aspects of the UI. Our goal is to design the UI to be as intuitive as possible, so users require minimal familiarization with the project. | +| **0c.** | Testing and Testing Guide | The ink! smart contract will undergo thorough testing, including e2e testing with a simulated zombienet network, to ensure maximum correctness. All UI interactions will undergo comprehensive testing to guarantee a seamless experience for users when using the RegionX UI. | +| **0d.** | Docker | We will provide Dockerfiles for the ink! smart contracts that will set up the environment and execute the contract tests. Additionally, we will offer a Dockerfile that will configure and run the RegionX UI. | +| 0e. | Article | We will compose a Medium article to offer a high-level explanation of the project's architecture. Within this article, we will clarify the significance of cross-chain region transfers and their crucial role in the Coretime market. | +| 1. | Cross-chain Transfer UI | We will create the UI for transferring the region NFTs from the Coretime parachain to the contracts parachain and vice versa. | +| 2. | Coretime Market Dashboard UI | In this milestone, we will also develop the Coretime Market dashboard UI. This section will be similar to the 'My Regions' dashboard, with the difference that it will display all the valid regions from the market instead of the regions owned by the user. Additionally, it will provide users with relevant information such as the cost of each region. The UI will also provide the option to buy or sell a region on the market. | +| 3. | Coretime Market contract | We will develop the Coretime market as an ink! smart contract, as described above in the _Secondary Market_ section. This contract will use the xcRegions contract developed in the previous milestone. It will introduce listing functionality, enabling sellers to set the price for their regions. The contract will implement a bit-level pricing model, which will gradually reduce the cost of regions over time as the region remains unused. When a buyer acquires a listed region, they will only be charged for the Coretime they are going to receive thanks to the dynamic pricing model. | +| 4. | Coretime Market developer documentation | We will create documentation to explain how to easily integrate the market contract developed in this milestone. Our goal is to enable many teams in the future to integrate the contracts that are developed as part of this proposal. | + +## Future Plans + +As mentioned at the beginning of the project details, this project consists of two other parts that are not developed as part of this application. The next describes the future plans categorized into these components. + +### Coretime Market + +As mentioned in the proposal we intend to further implement the **Region Derivation** feature. This will allow users to buy only a portion of the region that is being listed on sale. + +We also plan to finish the Coretime market UI, which will include more user-friendly region search and the ability to purchase portions of listed regions directly through the UI. + +Our plan is to have the market contract used by many other projects in the future. Since it would be highly beneficial for greater liquidity to utilize the same contract and not have many deployed, we plan to incorporate an economic model that incentivizes each of the projects using the same Coretime market contract. + +In the future, we also plan to transition from an Ink! contract to a parachain. This will provide us with greater flexibility over XCM, improved performance, and the possibility to more easily integrate with other pallets. Thanks to the greater flexibility on the parachain runtime side, in comparison to a contract, we have the potential to add a totally new way of buying Coretime. This would be possible by enabling users to pool funds, pre-define the ownership, and directly purchase a region from the Bulk market. + +### Data Analytics + +This component will provide users with the relevant information they need to better understand the Coretime market, empowering them to make informed decisions when buying or selling Cores. + +One of the pieces of data that will be displayed here is Coretime utilization. As a small prior experiment, we have created the following website that tracks the weight utilization from its maximum potential of each Polkadot and Kusama parachain: https://polkadot-weigher.com [twitter post](https://x.com/SakacSergej/status/1714270223489245505?s=20) + +### Developer Hub + +The developer hub will assist teams that have deployed tasks on Polkadot or Kusama in understanding their Coretime usage better. This is accomplished by providing a service of tracking Coretime consumption over time and presenting the data in graph form for the team. +In the developer hub, users can register custom KPIs and use built-in ones. By utilizing KPIs along with previous months' data, we could potentially create an advisor to suggest the ideal Coretime allocation. + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** GitHub diff --git a/applications/Relation-Graph.md b/applications/Relation-Graph.md index 79531b2ab1c..bb828f657ba 100644 --- a/applications/Relation-Graph.md +++ b/applications/Relation-Graph.md @@ -1,24 +1,23 @@ -# W3F Grant Proposal +# Relation Graph > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. > > See the [Grants Program Process](https://github.com/w3f/Grants-Program/#pencil-process) on how to submit a proposal. -- **Project Name:** Relation Graph + - **Team Name:** Relationlabs - **Payment Address:** 0x9fE784bD844C6c7eB7a570467937e6005eEd1C4C Ethereum (USDT/DAI) - **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/569#issuecomment-1299292773) - -## Project Overview :page_facing_up: +## Project Overview :page_facing_up ### Overview + `Relation Graph` is a substrate pallet that allows anyone to use GraphDB in [Substrate platform](https://substrate.io/). `Relation Graph` provides organizations with ready-to-use GraphDB service for successfully running Dapps on the Substrate. using `Relation Graph` Dapps builders can focus on bussiness logic by removing the complexities of Substrate. - ### Project Details - **Relation Graph** `Relation Graph` is a substrate pallet that allows anyone to use GraphDB in [Substrate platform](https://substrate.io/). @@ -28,9 +27,9 @@ 3、sparql as blockchain. It supports the following specifications: -* [SPARQL 1.1 Query](https://www.w3.org/TR/sparql11-query/), [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/), and [SPARQL 1.1 Federated Query](https://www.w3.org/TR/sparql11-federated-query/). -* [Turtle](https://www.w3.org/TR/turtle/), [TriG](https://www.w3.org/TR/trig/), [N-Triples](https://www.w3.org/TR/n-triples/), and [N-Quads](https://www.w3.org/TR/n-quads/). -* [SPARQL 1.1 Query Results JSON Format](https://www.w3.org/TR/sparql11-results-json/) and [SPARQL 1.1 Query Results CSV and TSV Formats](https://www.w3.org/TR/sparql11-results-csv-tsv/). +- [SPARQL 1.1 Query](https://www.w3.org/TR/sparql11-query/), [SPARQL 1.1 Update](https://www.w3.org/TR/sparql11-update/), and [SPARQL 1.1 Federated Query](https://www.w3.org/TR/sparql11-federated-query/). +- [Turtle](https://www.w3.org/TR/turtle/), [TriG](https://www.w3.org/TR/trig/), [N-Triples](https://www.w3.org/TR/n-triples/), and [N-Quads](https://www.w3.org/TR/n-quads/). +- [SPARQL 1.1 Query Results JSON Format](https://www.w3.org/TR/sparql11-results-json/) and [SPARQL 1.1 Query Results CSV and TSV Formats](https://www.w3.org/TR/sparql11-results-csv-tsv/). ![arch.png](https://user-images.githubusercontent.com/91399393/165587783-c55954fe-6d72-4702-95d9-75a4521e980d.png) @@ -59,7 +58,7 @@ INSERT DATA - Update Data -Changes to existing triples are performed as a delete operation followed by an insert operation in a single update request. +Changes to existing triples are performed as a delete operation followed by an insert operation in a single update request. The specification refers to this as `DELETE/INSERT` Sample SPARQL: update age to `36` for person `P001` @@ -83,6 +82,7 @@ DELETE WHERE :P001 ?p ?o . } ``` + Sample SPARQL: delete partial properties of person `P001` ```sparql @@ -92,6 +92,7 @@ DELETE WHERE :name ?name . } ``` + 2. SPARQL Query Call RPC `sparql_query` with SPARQL for `query` operations. @@ -102,7 +103,6 @@ curl -H "Content-Type: application/json" \ http://localhost:9933 ``` - ### Ecosystem Fit - Relation graph can effectively reduces the development threshold of building Web3 decentralized applications which contains large data. @@ -131,7 +131,7 @@ curl -H "Content-Type: application/json" \ ### Team's experience -- Jessica Chang Founder +- Jessica Chang Founder Crypto and commodity trader @@ -149,19 +149,19 @@ Led team of 200+ members AsiaInfo, HP, AWS - Santry Huang CMO -Former CMO at Patract Labs +Former CMO at Patract Labs 9+ years of marketing and operation and experience - Ben Zhang Chief Software Architect -former core development engineer of IBM, AWS and other companies, +former core development engineer of IBM, AWS and other companies, 10+ years of back-end development experience, Problem solving Bigdata - Joe Guo CPO -former product leader of top blockchain companies, +former product leader of top blockchain companies, 6+ years of project experience in finance, logistics, social networking, games products @@ -173,24 +173,21 @@ former product leader of top blockchain companies, ### Team LinkedIn Profiles (if available) -- Jessica Chang, Founder, https://www.linkedin.com/in/jessica-chang-a63313235/ -- Santry Huang, CMO, https://www.linkedin.com/in/santryhuang/ -- Yann， CTO， https://www.linkedin.com/in/yann-ren-361b91235/ +- Jessica Chang, Founder, https://www.linkedin.com/in/jessica-chang-a63313235/ +- Santry Huang, CMO, https://www.linkedin.com/in/santryhuang/ +- Yann， CTO， https://www.linkedin.com/in/yann-ren-361b91235/ - Joe，CPO，https://www.linkedin.com/in/joe-guo-783780ab/ ## Development Status :open_book: - - We have finished a version on Internet computer.It is a graph database written in Rust and deployed on WASM.Ereryone can try it here(https://kziov-eaaaa-aaaag-aaaxa-cai.ic0.app/ic_graph_developer.html). - ## Development Roadmap :nut_and_bolt: - **Total Estimated Duration:** 4 months - **Full-Time Equivalent (FTE):** 2 FTE - **Total Costs:** 30,000 USD - ### Milestone 1 — Relation Graph deploy as pallet，contains insert,query,delete and update - **Estimated duration:** 1 month @@ -203,7 +200,6 @@ former product leader of top blockchain companies, | 0b. | Documentation | We will provide inline documentation and a tutorial of use and deploy pallet | | 0c. | Testing Guide | We will add unit tests to cover all basic logic.| | 1. | wasm package | We will create a wasm package that can deployed as pallet,contains insert,query,delete and update| - ### Milestone 2— Expand the basic functions of database，contains ACL,OGM and subgraph @@ -237,6 +233,3 @@ former product leader of top blockchain companies, ## Future Plans - Based on Relation Graph, we intend to provide a Web3 social DAPP build on substrate. - - - diff --git a/applications/Roloi.md b/applications/Roloi.md index 4afa0517cb0..0d179f2fc01 100644 --- a/applications/Roloi.md +++ b/applications/Roloi.md @@ -1,6 +1,5 @@ -# W3F Grant Proposal +# Roloi -- **Project Name:** Roloi - **Team Name:** NeoPower - **Payment Address:** 0x1f5CE2eDdaAAe75ff62729feE50F861bCDC0b62e (ETH Network -> **USDT**) - **Level:** 2 diff --git a/applications/RubeusKeeper.md b/applications/RubeusKeeper.md new file mode 100644 index 00000000000..41b8a9fec6f --- /dev/null +++ b/applications/RubeusKeeper.md @@ -0,0 +1,138 @@ +# Rubeus Keeper + +- **Team Name:** Bela Supernova +- **Payment Address:** 0xC0d28794eA40Ce9b9F4B62a1B2Bb42FD34b7d305 (USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: +This application is not in response to an RFP, but it fully complies with a potentially interesting project “Sign-in with your Polkadot, Kusama, etc. account” mentioned in [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source) page in the “ browser extensions” section. + +### Overview + +Remembering passwords from all resources is a challenging task. It doesn’t need any introduction as all Internet users use passwords dozen times a day. The most common, but less reliable way of password managing is using the only password for all resources – not a good idea, but true. The other one, next most popular – using password managers built in your browser. Quite reliable for low critical data, but for privacy critical data this is not the way to store passwords as there are several ways for third parties to obtain passwords from these centralized systems. Users that value privacy usually use offline desktop applications for managing passwords – it’s safe, but has disadvantages as different devices won’t sync, so one has to manage them separately. + +The aim of this project is to develop a decentralized password manager that stores data in a blockchain and uses personal Polkadot wallet credentials to access the passwords manager dApp. Saved passwords will be added automatically to appropriate forms on websites after logging in with user’s wallet private key in the browser extension. + +### Project Details + +The Rubeus Keeper dApp will consist of two functional modules: +1. An Ink! smart contract for seсure password storage using a Polkadot or Kusama account. Just log in to your Polkadot wallet and get access to your passwords DB. The smart contract will includes methods for writing and getting passwords, as well as categorizing. +2. A browser extension for password managing: registration, log in, password generation, categorizing, saving, retrieving, autocomplete functionality. + +Under this MVP we consider security in the next attack vectors: + 1. Transferred data unauthorized interception and decryption (categories, URLs/logins, passwords). + 2. Malicious data substitution by a node. +To solve the above mentioned tasks the data will be encrypted using the ChaCha20-Poly1305 streaming algorithm with message authentication. The protocol is standardized by IETF in RFC 7539, in software implementations it is much more efficient and faster than AES. + +![Rubeus schema 3](https://user-images.githubusercontent.com/98888366/184879468-bb14b061-7e32-4f89-bc15-8d753d66f236.png) + +### Ecosystem Fit + +The Rubeus Keeper dApp will be used by all the community and even all Internet users as it simplifies and secures daily interaction with web applications – web2 or web3 – our dApp will be comprehensively useful. The target audience is “a web user”. + +In the [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source) we see the [Logion network]( https://github.com/logion-network/logion-node) project, that represents a separate parachain with very wide functionality. Unlike Logion we offer a simple Ink! contract and an extension that can be used in any Substrate based parachain with no need for setting nodes and etc. Fast, easy and no need for a separate wallet. + +## Team :busts_in_silhouette: + +### Team members + +- Sergey Cymbal, MBA, CEO at Bela Supernova d.o.o +- Dmitrii Putilov, Blockchain Department Director at Bela Supernova d.o.o +- Ilia Shavrin, Full stack software developer at Bela Supernova d.o.o +- Anton Shramko, Full stack software developer at Bela Supernova d.o.o +- Ksenia Baranova, QA Lead at Bela Supernova d.o.o +- Alexey Vexin, Project Manager at Bela Supernova d.o.o +- Anton Borisov, DevOps Engineer at Bela Supernova d.o.o + +### Contact + +- **Contact Name:** Alexey Vexin +- **Contact Email:** av@bsn.si +- **Website:** https://www.bsn.si + +### Legal Structure + +- **Registered Address:** Cesta v Mestni log 55, Ljubljana 1000, Slovenia +- **Registered Legal Entity:** BELA SUPERNOVA, sistemske rešitve d.o.o. + +### Team's experience + +Sergey Cymbal is an experienced executive, leader and visioner responsible for the most disruptive innovations initiatives across Oil/Gas, Utilities, and Telcos. Ex-member of winter Olympics HQ, responsible for digitalization, Smart grid evangelist. Blockchain early follower, participates in several crypto initiatives. + +Dmitrii Putilov has over 17 years of experience leading the teams creating and maintaining high availability sites. His portfolio contains creation of the robee.io investment platform included in top500 in coinmarketcap. + +Ilia Shavrin is a solution architect and full stack software developer with over 12 years of experience in high load enterprise applications. His most recent focus is on blockchain and creation of decentralized applications. + +Anton Shramko is an experienced developer with 7 years of experience on various positions, including solution architect in Krypton. Anton active contributor to open source and blockchain communities, he is also a frequent speaker in DevCon conferences. + +Ksenia Baranova is an QA test engineer with over 5 years of experience. Ksenia has exceptional knowledge and skills in the field. She is highly referred within this team, as well as by her former teams. + +Alexey Vexin is a product owner and a project manager with 15+ years of experience in managing complicated telecoms and IT projects in Telco, Utilities and Governmental sectors with deep focus on business process management. Led a dozen of national scaled projects for IT systems implementation and industry scaled technology development, standardization and implementation. + +Anton Borisov is a DevOps Engineer with broad experience. For over 15 years Anton was supporting, administering, and maintaining secure networks, servers, and clusters. He also has versatile experience with CI/CD, IT Infrastructure Monitoring, and Kubernetes on-premise and in Cloud. One of the most recent projects Anton participated in was building a first on chain casino. + +Bela Supernova has delivered a W3f grant earlier: [OCEX](https://github.com/w3f/Grants-Program/pull/803#issuecomment-1064184965) + +BSN also has 2 active projects under FileCoin, Chainlink and Tgrade grants. + +### Team Code Repos + +- https://github.com/orgs/bsn-si/repositories +- https://github.com/ManageIQ/manageiq-providers-amazon/commits?author=aiperon +- https://github.com/ManageIQ/manageiq/commits/?author=aiperon +- https://github.com/friktor?tab=repositories +- https://github.com/dsputilov +- https://github.com/friktor +- https://github.com/aiperon + +### Team LinkedIn Profiles (if available) + +- [Sergey Cymbal] (https://www.linkedin.com/in/sergecymbal/) +- [Dmitrii Putilov] (https://www.linkedin.com/in/dmitri-p-96b0a140/) +- [Ilia Shavrin] (https://www.linkedin.com/in/ilia-shavrin-716552228/) +- [Anton Shramko] (https://www.linkedin.com/in/anton-shramko-25971b162/) +- [Ksenia Baranova] (https://www.linkedin.com/in/mayawotson/) +- [Alexey Vexin] (https://www.linkedin.com/in/alexey-vexin-800a4068/) +- [Anton Borisov] + +## Development Roadmap :nut_and_bolt: + +We plan to execute 2 deliverables in two milestones: +- an Ink! smart contract for password storage; +- a browser extension for password management (tested under Chrome browser). + +The project will be supported by a team of 2 developers, 1 UI/UX designer, 1 DevOps engineer and 1 QA. + +### Overview + +- **Total Estimated Duration:** 2,5 months +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 30,000 USDT + +### Milestone 1 — Design and development of a smart-contract and a testing page + +- **Estimated Duration:** 1,5 months +- **FTE:** 2 FTE +- **Costs:** 22,000 USDT + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can run our smart contract and send test transactions, which will show how the functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 1. | Ink! smart-contract | An Ink! smart-contract for password storage and use: “add password (title, url, username, password, comment)”, “delete password”, “get password”, “add category”, “delete category”, “get categories”. Stored data will be encrypted using the ChaCha20-Poly1305 streaming algorithm with message authentication. | +| 2. | Test page | A test page for running functional tests: categories (get data from a blockchain, decrypt received data, unzip and get passwords, categories list render, passwords list render by categories); save password (data entry form, data serialization, zip data, data encryption, send transaction); show balance. The test page will be developed using JavaScript. | + +### Milestone 2 — Design and development of a browser extension + +- **Estimated Duration:** 1 month +- **FTE:** 1 FTE +- **Costs:** 8,000 USDT + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can run our smart contract and send test transactions, which will show how the functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness under the Chrome browser. In the guide, we will describe how to run these tests. | +| 0d. | Article | We will publish an **article** that explains what was achieved, how to use the new Dapp and what are the benefits of using the system | +| 1. | Browser extension | A Chrome browser extension MVP for password management: a registration page (login with a Polkadot wallet private key and set a master-password); login page (using master-password); categories (get data from a blockchain, decrypt received data, unzip and get passwords, categories list render, passwords list render by categories); save password (data entry form, data serialization, zip data, data encryption, send transaction); password generation window, show balance. The extension will be developed using JavaScript. | diff --git a/applications/Rubeus_keeper_st2.md b/applications/Rubeus_keeper_st2.md new file mode 100644 index 00000000000..54efba9251e --- /dev/null +++ b/applications/Rubeus_keeper_st2.md @@ -0,0 +1,161 @@ +# Rubeus Keeper stage 2 + +- **Team Name:** Bela Supernova +- **Payment Address:** Polkadot (Statemint): 15iqY5VMHAbwkPs4ooJJazLND8Z9uPJXRrbwDE1zcPfeYwZJ (USDT) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: + +This application is a follow-up grant of the [Rubeus Keeper]( https://github.com/w3f/Grants-Program/pull/1124) project. + +### Overview + +Remembering passwords from all resources is a challenging task. It doesn’t need any introduction as all Internet users use passwords dozen times a day. The most common, but less reliable way of password managing is using the only password for all resources – not a good idea, but true. The other one, next most popular – using password managers built in your browser. Quite reliable for low critical data, but for privacy critical data this is not the way to store passwords as there are several ways for third parties to obtain passwords from these centralized systems. Users that value privacy usually use offline desktop applications for managing passwords – it’s safe, but has disadvantages as different devices won’t sync, so one has to manage them separately. + +The aim of this project is to develop a decentralized password manager that stores data in a blockchain and uses personal Polkadot wallet credentials to access the passwords manager dApp. Saved passwords will be added automatically to appropriate forms on websites after logging in with user’s wallet private key in the browser extension. +Another feature of the Rubeus dApp is storing personal text notes. + +### Project Details + +In the first stage of the project we’ve delivered: +- An Ink! smart contract for seсure password storage using a Polkadot or Kusama account. Just log in to your Polkadot wallet and get access to your passwords DB. The smart contract includes methods for writing and getting passwords, as well as categorizing them. +- A browser extension for password managing: log in, password generation, categorizing, saving, retrieving. + +![Rubeus schema 3](https://user-images.githubusercontent.com/98888366/207593938-268d7c72-e5bd-46cc-94a6-105466bd233e.png) + +In this follow-up grant BSN will improve the functionality of the developed dApp by adding the following features: +1. Autocomplete functionality for the developed browser extension with password autogeneration feature. +2. New methods for the Ink! smart contract for secure text notes storage: saving, retrieving, deleting, updating. +3. Functionality for registering a new wallet (private key) in the dApp, password (seed phrase) recovery mechanism by downloading a JSON file. + +![Rubeus st2 schema](https://user-images.githubusercontent.com/98888366/207593980-0a71eefa-dd48-4814-93b1-74ffb308eb0b.png) + +### Ecosystem Fit + +The Rubeus Keeper dApp will be used by all the community and even all Internet users as it simplifies and secures daily interaction with web applications – web2 or web3 – our dApp will be comprehensively useful. The target audience is “a web user”. + +If we take a glance at the [Open Source Polkadot Stack](https://wiki.polkadot.network/docs/build-open-source) we see the [Logion network]( https://github.com/logion-network/logion-node) project, that represents a separate parachain with very wide functionality. Unlike Logion we offer a simple Ink! contract and an extension that can be used in any Substrate based parachain with no need for setting nodes and etc. Fast, easy and no need for a separate wallet. + +## Team :busts_in_silhouette: + +### Team members + +- Sergey Cymbal, MBA, CEO at Bela Supernova d.o.o +- Dmitrii Putilov, Blockchain Department Director at Bela Supernova d.o.o +- Ilia Shavrin, Full stack software developer at Bela Supernova d.o.o +- Anton Shramko, Full stack software developer at Bela Supernova d.o.o +- Ksenia Baranova, QA Lead at Bela Supernova d.o.o +- Alexey Vexin, Project Manager at Bela Supernova d.o.o +- Anton Borisov, DevOps Engineer at Bela Supernova d.o.o + +### Contact + +- **Contact Name:** Alexey Vexin +- **Contact Email:** av@bsn.si +- **Website:** https://www.bsn.si + +### Legal Structure + +- **Registered Address:** Cesta v Mestni log 55, Ljubljana 1000, Slovenia +- **Registered Legal Entity:** BELA SUPERNOVA, sistemske rešitve d.o.o. + +### Team's experience + +Sergey Cymbal is an experienced executive, leader and visioner responsible for the most disruptive innovations initiatives across Oil/Gas, Utilities, and Telcos in Russia. Ex-member of Sochi Olympics HQ, responsible for digitalization, Smart grid evangelist. Blockchain early follower, participates in several crypto initiatives. + +Dmitrii Putilov has over 17 years of experience leading the teams creating and maintaining high availability sites. His portfolio contains creation of the robee.io investment platform included in top500 in coinmarketcap. + +Ilia Shavrin is a solution architect and full stack software developer with over 12 years of experience in high load enterprise applications. His most recent focus is on blockchain and creation of decentralized applications. + +Anton Shramko is an experienced developer with 7 years of experience on various positions, including solution architect in Krypton. Anton active contributor to open source and blockchain communities, he is also a frequent speaker in DevCon conferences. + +Ksenia Baranova is an QA test engineer with over 5 years of experience. Ksenia has exceptional knowledge and skills in the field. She is highly referred within this team, as well as by her former teams. + +Alexey Vexin is product owner and project manager with 10+ years of experience in managing complicated telecoms and IT projects in Telco, Utilities and Governmental sectors with deep focus on business process management. Led a dozen of federal scaled projects for IT systems implementation and industry scaled technology development, standardization and implementation. + +Anton Borisov is a DevOps Engineer with broad experience. For over 15 years Anton was supporting, administering, and maintaining secure networks, servers, and clusters. He also has versatile experience with CI/CD, IT Infrastructure Monitoring, and Kubernetes on-premise and in Cloud. One of the most recent projects Anton participated in was building a first on chain casino. + +Bela Supernova has finished W3f grants earlier: +[OCEX](https://github.com/w3f/Grants-Program/pull/803#issuecomment-1064184965) +[Rubeus Keeper]( https://github.com/w3f/Grants-Program/pull/1124) + +BSN also delivers code under successful and active grants from FileCoin, Chainlink and Tgrade communities. + +### Team Code Repos + +- https://github.com/orgs/bsn-si/repositories +- https://github.com/ManageIQ/manageiq-providers-amazon/commits?author=aiperon +- https://github.com/ManageIQ/manageiq/commits/?author=aiperon +- https://github.com/friktor?tab=repositories +- https://github.com/dsputilov +- https://github.com/friktor +- https://github.com/aiperon + +### Team LinkedIn Profiles (if available) + +- [Sergey Cymbal] (https://www.linkedin.com/in/sergecymbal/) +- [Dmitrii Putilov] (https://www.linkedin.com/in/dmitri-p-96b0a140/) +- [Ilia Shavrin] (https://www.linkedin.com/in/ilia-shavrin-716552228/) +- [Anton Shramko] (https://www.linkedin.com/in/anton-shramko-25971b162/) +- [Ksenia Baranova] (https://www.linkedin.com/in/mayawotson/) +- [Alexey Vexin] (https://www.linkedin.com/in/alexey-vexin-800a4068/) +- [Anton Borisov] + +## Development Status :open_book: + +This application is a follow-up grant of a [Rubeus Keeper]( https://github.com/w3f/Grants-Program/pull/1124) project. +Reps: +[Rubeus Ink! smart contract](https://github.com/bsn-si/rubeus-smartcontract) +[Rubeus client](https://github.com/bsn-si/rubeus-client) + +## Development Roadmap :nut_and_bolt: + +We plan to execute 3 deliverables in three milestones: +- new methods for the Ink! smart contract for text notes storage; +- an autocomplete feature for the browser extension for passwords autofill (tested under Chrome browser); +- a password generation tool. + +The project will be supported by a team of 2 developers, 1 UI/UX designer, 1 DevOps engineer and 1 QA. + +### Overview + +- **Total Estimated Duration:** 2 months +- **Full-Time Equivalent (FTE):** 2,8 FTE +- **Total Costs:** 25,000 USDT + +### Milestone 1 — Design and development of text notes storage methods + +- **Estimated duration:** 1 month +- **FTE:** 1,5 +- **Costs:** 13,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can send test transactions, which will show how the new functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure new functionality and robustness. In the guide, we will describe how to run these tests. | +| 1. | Ink! smart-contract | The Rubeus smart-contract supplemented with new methods for text notes storage and use: “add note (title, contents)”, “delete note”, “get notes” and “update note”. | +| 2. | Extension “notes” tab | An MVP for the Chrome browser extension tab for text notes management: notes list (get data from a blockchain, decrypt received data, unzip and get text notes, text notes list render); save a text note (data entry form, data serialization, zip data, data encryption, send transaction), delete a text note, update a note. | + +### Milestone 2 — Autocomplete (autofill) feature development + +- **Estimated duration:** 1 month +- **FTE:** 1,3 +- **Costs:** 12,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | Apache 2.0 | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can run our smart contract and send test transactions, which will show how the functionality works. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Article | We will publish an **article** that explains what was achieved, how to use the new Dapp and what benefits what are the benefits of using the system +| 1. | Browser extension autofill feature | We will develop additional functionality for the browser extension: - registration and authorization forms tracking; - suggestion to generate and save a password; - generation of a random password with user-defined rules; - autofill password forms on websites (tested on 5+ different web sites). To access passwords and manipulate them while the extension pop-up is closed we will rearrange the extension and transfer some logic to the service worker; | +| 2. | Password generation tool | We will develop a tool for a random password generation with user-defined rules. | + +Sample image of a password generation tool: + +Rubeus st2 pswd gen + +## Future Plans + +In the future plans for Rubeus we see widening of its functionality: from remembering credit cards credentials to answers for recovery questions. Everything that should be remembered for a personal use and complies with GDPR could be stored with Rubeus. A 2FA feature is also in our plans. All this should be developed under a later stage of the project. diff --git a/applications/RubyProtocol.md b/applications/RubyProtocol.md index f3a9dc46cd7..0990c72e912 100644 --- a/applications/RubyProtocol.md +++ b/applications/RubyProtocol.md @@ -1,57 +1,59 @@ -# Ruby Protocol - Open Grants Program +# Ruby Protocol - -* **Project:** Ruby Protocol -* **Proposer:** Ruby Protocol -* **Payment Address:** 0x5aBBe7b65c572b9f5Cc7655Ba4a1Acad0e892720 +- **Proposer:** Ruby Protocol +- **Payment Address:** 0x5aBBe7b65c572b9f5Cc7655Ba4a1Acad0e892720 ## Project Overview :page_facing_up: + ### Overview + #### Introduction This project will design and implement a fine-grained personal data monetization framework, which would serve as a second-layer/middleware protocol interacting with the substrate module. The framework will enable a data owner to enforce a fine-grained access control policy over his/her encrypted private data using functional encryption, and share predefined computation results over the private data with a data purchaser in exchange for economic compensation. The access control policy will be built into the substrate module, and the data monetization transaction will also execute via substrate module, which is why this solution is defined as a second-layer/middleware protocol. ### Project Details + #### Project Architecture -Functional encryption was originally proposed as a fine-grained access control mechanism over encrypted data [GPSW06]. A data owner encrypts a message `x` to generate ciphertext, which could be stored in an untrusted cloud server. The project might pay for the hosting expenses initially to jump-start the project, but we will gradually transfer the cost to the data owner since it would make sense for them to pay for their data monetization business. A data purchaser might wish to compute a function `f` over the encrypted message. With the consent of the data owner, a data purchaser would receive a secret key `sk_f` from a key distributor. The data purchaser can then use the private key `sk_f` to decrypt the ciphertext to compute `f(x)`. Note the data purchaser cannot retrieve any other information on the underlying message except the final decryption result `f(x)`. To prevent the data owner from accepting payment and then immediately removing their data from the cloud before the data purchaser receives the data, the data purchaser needs to retrieve the encrypted data before paying the owner. +Functional encryption was originally proposed as a fine-grained access control mechanism over encrypted data [GPSW06]. A data owner encrypts a message `x` to generate ciphertext, which could be stored in an untrusted cloud server. The project might pay for the hosting expenses initially to jump-start the project, but we will gradually transfer the cost to the data owner since it would make sense for them to pay for their data monetization business. A data purchaser might wish to compute a function `f` over the encrypted message. With the consent of the data owner, a data purchaser would receive a secret key `sk_f` from a key distributor. The data purchaser can then use the private key `sk_f` to decrypt the ciphertext to compute `f(x)`. Note the data purchaser cannot retrieve any other information on the underlying message except the final decryption result `f(x)`. To prevent the data owner from accepting payment and then immediately removing their data from the cloud before the data purchaser receives the data, the data purchaser needs to retrieve the encrypted data before paying the owner. Here is a more concrete example for functional encryption: the message here could be the user’s genomic data, and `f` could be a statistical analysis algorithm. The data purchaser could be a research institute intended to perform private statistical analysis over one’s genomic data. The secret key might be generated by the hospital that collects the users' genomic data or the data owner themselves. At the end of this transaction, the data owner will receive economic compensation for one's contribution to the computation result while the data purchaser will receive the statistical analysis results. In other cases, the data could also be one’s social network data and the function could be an analytics algorithm for online advertisement. We envision the monetary exchange between the data owner and purchaser will be executed as a substrate module. This project will implement a second-layer/middleware protocol running on Polkadot that enables individuals to monetize their private data in a fine-grained fashion. The delivery will include: -* A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. -* A substrate module that implements the encryption of the cryptographic keys of the functional encryption scheme and the associated zero-knowledge proof for its legitimacy. -* A micropayment scheme running on the Polkadot blockchain can allow individual users to monetize their data. -Here are the basic principles behind the overall architecture design of the fine-grained personal data monetization framework. We aim to keep the workload of the data owner minimum. This implies the online time of the data owner should be kept to a minimum. The optimal case would be the data owner is left alone after he generates and uploads the ciphertext. Ideally, the encryption workload of the data owner should also be kept as minimal as possible. The following scheme can be viewed as a generalization of the knowledge monetization scheme proposed in [TZLHJS2017]. +- A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. +- A substrate module that implements the encryption of the cryptographic keys of the functional encryption scheme and the associated zero-knowledge proof for its legitimacy. +- A micropayment scheme running on the Polkadot blockchain can allow individual users to monetize their data. -The general idea is shown in Fig. 1. A functional encryption scheme usually consists of four algorithms:`FE.Setup(1^\lambda)`, `FE.KeyGen(msk, f)`, `FE.Enc(mpk, x)` and `FE.Decrypt(Key_f, FE.Enc(mpk, x))`. At the beginning of the system, the key distributors run the `FE.Setup(1^\lambda)` algorithm to generate the master public key `mpk` and master secret key `msk`. Here `\lambda` denotes the security parameter. When a data owner wishes to sell his data, he encrypts his data `x` by running the `FE.Enc(mpk, x)` algorithm and uploads the output ciphertext `Enc(x)` to the untrusted cloud. He then specifies the pricing model with respect to different functions `f`’s in a substrate module SC, and posts it to the Polkadot blockchain. When a data purchaser intends to calculate `f(x)`, he will first generate a commitment of an appropriate amount of coin based on the pricing of the function `f` and his own public key `PK_P` as a transaction to call the module SC. +Here are the basic principles behind the overall architecture design of the fine-grained personal data monetization framework. We aim to keep the workload of the data owner minimum. This implies the online time of the data owner should be kept to a minimum. The optimal case would be the data owner is left alone after he generates and uploads the ciphertext. Ideally, the encryption workload of the data owner should also be kept as minimal as possible. The following scheme can be viewed as a generalization of the knowledge monetization scheme proposed in [TZLHJS2017]. + +The general idea is shown in Fig. 1. A functional encryption scheme usually consists of four algorithms:`FE.Setup(1^\lambda)`, `FE.KeyGen(msk, f)`, `FE.Enc(mpk, x)` and `FE.Decrypt(Key_f, FE.Enc(mpk, x))`. At the beginning of the system, the key distributors run the `FE.Setup(1^\lambda)` algorithm to generate the master public key `mpk` and master secret key `msk`. Here `\lambda` denotes the security parameter. When a data owner wishes to sell his data, he encrypts his data `x` by running the `FE.Enc(mpk, x)` algorithm and uploads the output ciphertext `Enc(x)` to the untrusted cloud. He then specifies the pricing model with respect to different functions `f`’s in a substrate module SC, and posts it to the Polkadot blockchain. When a data purchaser intends to calculate `f(x)`, he will first generate a commitment of an appropriate amount of coin based on the pricing of the function `f` and his own public key `PK_P` as a transaction to call the module SC.
          - +
          -The substrate module should return a receipt to the data purchaser, who will in turn present it to the key distributor. The key distributor, after verifying the receipt and the respective coin commitment, runs the `FE.KeyGen(msk, f)` algorithm to generate the function key `Key_f` for the data purchaser. +The substrate module should return a receipt to the data purchaser, who will in turn present it to the key distributor. The key distributor, after verifying the receipt and the respective coin commitment, runs the `FE.KeyGen(msk, f)` algorithm to generate the function key `Key_f` for the data purchaser. -Simultaneously, the distributor will send SC the encryption of `Key_f` under the data purchaser’s public key `PK_P`, denoted as `Enc_(PK_P)(Key_f)` and an associated zero-knowledge proof proving `Key_f` is indeed a well-formed function key corresponding to `f`. SC with the inputs from both the key distributor and data purchaser is then verified by the Polkadot blockchain. Once the verification for both sides passes, meaning the amount of the committed coin is sufficient to pay for the decryption result `f(x)` and the gas fee, and the associated zero-knowledge proof is correct, the payment will be released to the data owner. The data purchaser can then download the ciphertext and decrypt `f(x)` by running the `FE.Decrypt(Key_f, FE.Enc(mpk, x))` algorithm. +Simultaneously, the distributor will send SC the encryption of `Key_f` under the data purchaser’s public key `PK_P`, denoted as `Enc_(PK_P)(Key_f)` and an associated zero-knowledge proof proving `Key_f` is indeed a well-formed function key corresponding to `f`. SC with the inputs from both the key distributor and data purchaser is then verified by the Polkadot blockchain. Once the verification for both sides passes, meaning the amount of the committed coin is sufficient to pay for the decryption result `f(x)` and the gas fee, and the associated zero-knowledge proof is correct, the payment will be released to the data owner. The data purchaser can then download the ciphertext and decrypt `f(x)` by running the `FE.Decrypt(Key_f, FE.Enc(mpk, x))` algorithm. -Note once the verification of SC is passed, SC will execute and payment is released to the data owner instantaneously. To ensure fairness towards the data purchaser, the data owner should provide verifiable evidence to prove his data source. `FE.Enc(x)` is accompanied by a certified signature `Sig_D(FE.Enc(x))` to prove the data is coming from the right source and thus the data quality can be guaranteed. Here D denotes the private key of the data source. The data source could charge an extra service fee from the data owner when the data owner first meets the data source (goes to the hospital and does the test in the genomic computation example) and decides to join the monetization program. We note even though the data source (the hospital in the genomic computation example) is the one that produces the data, it doesn't necessarily mean that it owns the patients' data. For instance, according to [this report](https://www.forbes.com/sites/forbestechcouncil/2018/04/23/who-really-owns-your-health-data/?sh=1499f91d6d62), some states in the US explicitly give patients ownership of their health data. In other words, only the patient can dictate how the data should be monetized. Although it might be tempting to let the data source be representative of the data owners and handle the monetization of their private data, it would both go against both the law and the ethos of the project, which is to put the control of one's data back in the hands of the owner. +Note once the verification of SC is passed, SC will execute and payment is released to the data owner instantaneously. To ensure fairness towards the data purchaser, the data owner should provide verifiable evidence to prove his data source. `FE.Enc(x)` is accompanied by a certified signature `Sig_D(FE.Enc(x))` to prove the data is coming from the right source and thus the data quality can be guaranteed. Here D denotes the private key of the data source. The data source could charge an extra service fee from the data owner when the data owner first meets the data source (goes to the hospital and does the test in the genomic computation example) and decides to join the monetization program. We note even though the data source (the hospital in the genomic computation example) is the one that produces the data, it doesn't necessarily mean that it owns the patients' data. For instance, according to [this report](https://www.forbes.com/sites/forbestechcouncil/2018/04/23/who-really-owns-your-health-data/?sh=1499f91d6d62), some states in the US explicitly give patients ownership of their health data. In other words, only the patient can dictate how the data should be monetized. Although it might be tempting to let the data source be representative of the data owners and handle the monetization of their private data, it would both go against both the law and the ethos of the project, which is to put the control of one's data back in the hands of the owner. -The design of the underlying functional encryption scheme, where the private key should correspond to the function chosen by the data purchaser. Since the encryption of the private key should be presented as evidence (as shown in Fig. 1) and verified on the blockchain, the private key should be of minimum size, preferably constant size. To keep the workload of both the data owner and key distributor minimal, the encryption time and key generation time should be as short as possible. +The design of the underlying functional encryption scheme, where the private key should correspond to the function chosen by the data purchaser. Since the encryption of the private key should be presented as evidence (as shown in Fig. 1) and verified on the blockchain, the private key should be of minimum size, preferably constant size. To keep the workload of both the data owner and key distributor minimal, the encryption time and key generation time should be as short as possible. -There exist several functional encryption schemes with constant key size such as the one presented in [SC2017,CRH2015, RDGBP2019,B2017,MSHBM2019]. General predicate encryption allows the data owner to encrypt the raw data items tagged with various attributes, and a data purchaser to query different parts of the data repository using a function key corresponding to a predicate. Inner product predicate encryption [CGW2015] is a special kind of predicate encryption, where the data purchaser could retrieve the data records if the inner product of their attribute vector `y` and the predicate vector `x` specified by the data purchaser is equal to 0. For instance, the data purchaser could potentially ask for the data records corresponding to a conjunctive predicate such as “Age”AND“gender”AND“Income” from a personal data repository. One of the most efficient inner product encryption schemes [CGW2015] has a private key consisting of four elliptic curve group elements, and its key generation is dominated by four modular exponentiations. +There exist several functional encryption schemes with constant key size such as the one presented in [SC2017,CRH2015, RDGBP2019,B2017,MSHBM2019]. General predicate encryption allows the data owner to encrypt the raw data items tagged with various attributes, and a data purchaser to query different parts of the data repository using a function key corresponding to a predicate. Inner product predicate encryption [CGW2015] is a special kind of predicate encryption, where the data purchaser could retrieve the data records if the inner product of their attribute vector `y` and the predicate vector `x` specified by the data purchaser is equal to 0. For instance, the data purchaser could potentially ask for the data records corresponding to a conjunctive predicate such as “Age”AND“gender”AND“Income” from a personal data repository. One of the most efficient inner product encryption schemes [CGW2015] has a private key consisting of four elliptic curve group elements, and its key generation is dominated by four modular exponentiations. -While the predicate encryption allows the data purchaser to retrieve different parts of a database based on a predefined predicate, a more general functional encryption allows the data purchaser to calculate an arbitrary function over the input `x`. This project will focus on a slightly narrow set of functional encryption schemes: inner product encryption and quadratic polynomial function encryption [MSHBM2019]. In an inner product encryption scheme, for encryption of a vector `x`, the data purchaser with a private key corresponding to another vector `y` will be able to compute the inner product between `x` and `y`. On the other hand, in a quadratic polynomial functional encryption scheme, the data owner will encrypt two vectors `v_1 \in \mathbb{Z}_n` and `v_2 \in \mathbb{Z}_n`, a data purchaser with a secret key corresponding to a matrix `H \in \mathbb{Z}^{n*n}` is allowed to decrypt the quadratic product of `x_1, x_2`, and `H`, i.e., `x_1^T\cdot H \cdot x_2`. Both inner product encryption and quadratic polynomial functional encryption can support sophisticated privacy-preserving machine learning tasks, such as classification [LCFS2017,SGP2018] and neural networks [RDGBP2019]. +While the predicate encryption allows the data purchaser to retrieve different parts of a database based on a predefined predicate, a more general functional encryption allows the data purchaser to calculate an arbitrary function over the input `x`. This project will focus on a slightly narrow set of functional encryption schemes: inner product encryption and quadratic polynomial function encryption [MSHBM2019]. In an inner product encryption scheme, for encryption of a vector `x`, the data purchaser with a private key corresponding to another vector `y` will be able to compute the inner product between `x` and `y`. On the other hand, in a quadratic polynomial functional encryption scheme, the data owner will encrypt two vectors `v_1 \in \mathbb\{Z}_n` and `v_2 \in \mathbb\{Z}_n`, a data purchaser with a secret key corresponding to a matrix `H \in \mathbb\{Z}^\{n*n}` is allowed to decrypt the quadratic product of `x_1, x_2`, and `H`, i.e., `x_1^T\cdot H \cdot x_2`. Both inner product encryption and quadratic polynomial functional encryption can support sophisticated privacy-preserving machine learning tasks, such as classification [LCFS2017,SGP2018] and neural networks [RDGBP2019]. The benchmark results for various inner product encryption and quadratic polynomial function encryption schemes can be found in [MSHBM2019]. The private key of inner product encryption consists of one elliptic curve group element, which is of 256 bits under 128-bit level security. The key generation for a vector of 100 elements takes 0.4149s, and the encryption time for the data owner is around 0.2103s for a vector of the same size. The private key of quadratic polynomial functional encryption also only consists of one elliptic curve group element. The average key generation and encryption time for each coordinate of the message vector is 0.001s and 0.025s. In terms of the accompanied zero-knowledge proof scheme, the statement of the zero-knowledge proof scheme should be to convince the verifier that the encrypted content is a well-formed function key with regards to a predefined function in the module. Since the verification of the zero-knowledge proof should be verified by the blockchain, we need to make sure the verification is efficient and the proof size is as small as possible. The candidate zero-knowledge proof scheme for this is zk-snark implementation such as [ZeroPool](https://github.com/zeropoolnetwork/zeropool-substrate), which is an implementation of Groth16 scheme. The proof generation time is comparatively short for the previously mentioned encryption schemes since the respective statement (determined by the key generation algorithm and the public key encryption) is quite simple. -According to the pricing model of data monetization, a report presented by OECD [RRS2013] classifies the existing practical pricing models of personal data into two major categories: based on market valuation and individual valuation. The approach based on individual valuation suffers from the defect that the individual valuation of the private data is extremely context-dependent and cannot be measured with precision and certainty. The market-valuation-based approach can be further divided into the following sub-categories: market cap per data record, market prices for data, cost of a data breach, and data prices in illegal markets. +According to the pricing model of data monetization, a report presented by OECD [RRS2013] classifies the existing practical pricing models of personal data into two major categories: based on market valuation and individual valuation. The approach based on individual valuation suffers from the defect that the individual valuation of the private data is extremely context-dependent and cannot be measured with precision and certainty. The market-valuation-based approach can be further divided into the following sub-categories: market cap per data record, market prices for data, cost of a data breach, and data prices in illegal markets. -The approach based on market prices for data is particularly interesting given that data brokers usually publicly broadcast their asking prices for various personal data records. Our platform can easily aggregate and compare across various data brokers to use it as the proxy pricing model of the individual personal data record. One could further refine these data prices based on the queried function and adopt a fine-grained pricing approach used by DirectMail [MDJM2019]. They give an example where the base price per record is equal to $0.045 and the predicate-based price per record is equal to $0.0035 + $0 + $0.004 = $0.0075 (for example, calculated from the aforementioned conjunctive predicate). Thus, the total price per record for predicate encryption would be equal to $0.045 + $0.0075 = $0.0525. For the inner product encryption or quadratic polynomial function encryption, the price of the decryption result will exclude the base price of the record. +The approach based on market prices for data is particularly interesting given that data brokers usually publicly broadcast their asking prices for various personal data records. Our platform can easily aggregate and compare across various data brokers to use it as the proxy pricing model of the individual personal data record. One could further refine these data prices based on the queried function and adopt a fine-grained pricing approach used by DirectMail [MDJM2019]. They give an example where the base price per record is equal to $0.045 and the predicate-based price per record is equal to $0.0035 + $0 + $0.004 = $0.0075 (for example, calculated from the aforementioned conjunctive predicate). Thus, the total price per record for predicate encryption would be equal to $0.045 + $0.0075 = $0.0525. For the inner product encryption or quadratic polynomial function encryption, the price of the decryption result will exclude the base price of the record. -This will be one of the pricing strategies we adopt in phase 1 and phase 2 of our project. In the later development of our project, we will explore more algorithmic pricing approaches such as Automated Market Maker’s (AMMs), where the platform estimates how much the data purchaser is willing to pay for data of different qualities and determines the concrete data pricing model. +This will be one of the pricing strategies we adopt in phase 1 and phase 2 of our project. In the later development of our project, we will explore more algorithmic pricing approaches such as Automated Market Maker’s (AMMs), where the platform estimates how much the data purchaser is willing to pay for data of different qualities and determines the concrete data pricing model. #### Team Interest @@ -64,45 +66,50 @@ We will leverage the existing cryptographic library in the Polkadot ecosystem, s ##### Open API and SDK The ultimate goal of Ruby Protocol is to provide an essential open API and SDK from a high-level perspective with the above tools, fully powering the data monetization framework on Polkadot, including: -* A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. A substrate module that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. -* The client can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms. + +- A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. A substrate module that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. +- The client can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms. #### Ecosystem Fits -The existing internet economic model relies almost exclusively on the monetization of personal data. The recent scandals on the internet companies mishandling individual data such as Facebook’s Cambridge Analytica scandal have prompted many individuals to awaken to the fact that in the current internet economy they are the product and they need to regain control over their data. In fact, I would argue that the recently published privacy regulation such as GDPR or CCPA is the response to this urge. -Polkadot could act as an indispensable role to remove the middleman of the internet economy. A second-layer fine-grained personal data monetization framework based on Polkadot would potentially move Polkadot beyond a decentralized financial platform and enable Polkadot to play a central role in the next-generation data economy. It would also enable Polkadot to gain a moral high ground by freeing billions of web users from the control of monopoly middleman companies. +The existing internet economic model relies almost exclusively on the monetization of personal data. The recent scandals on the internet companies mishandling individual data such as Facebook’s Cambridge Analytica scandal have prompted many individuals to awaken to the fact that in the current internet economy they are the product and they need to regain control over their data. In fact, I would argue that the recently published privacy regulation such as GDPR or CCPA is the response to this urge. -The following is the reason why a cross-chain platform such as Polkadot is a perfect platform to implement a decentralized and transparent data monetization mechanism: -The monetary return of one single data monetization transaction tends to be small. The economic benefit to the data owner can only be noticeable when this type of micropayment happens frequently. However, the mental cost incurred by having to deal with frequent micropayment might render it undesirable. Substrate module as publicly verifiable, self-enforcing code could help amortize the mental cost. +Polkadot could act as an indispensable role to remove the middleman of the internet economy. A second-layer fine-grained personal data monetization framework based on Polkadot would potentially move Polkadot beyond a decentralized financial platform and enable Polkadot to play a central role in the next-generation data economy. It would also enable Polkadot to gain a moral high ground by freeing billions of web users from the control of monopoly middleman companies. -The substrate module will specify the types of computation the data purchaser is allowed to perform over the ciphertext. Since the same computation result could be of different values to different data purchasers, automatic payment based on substrate module could be used to enforce sophisticated pricing models to guarantee the maximum economic return for the data owner. +The following is the reason why a cross-chain platform such as Polkadot is a perfect platform to implement a decentralized and transparent data monetization mechanism: +The monetary return of one single data monetization transaction tends to be small. The economic benefit to the data owner can only be noticeable when this type of micropayment happens frequently. However, the mental cost incurred by having to deal with frequent micropayment might render it undesirable. Substrate module as publicly verifiable, self-enforcing code could help amortize the mental cost. -A publicly verifiable substrate module would not only help with the transparent enforcement of various privacy regulations such as General data protection regulation (GDPR) or California consumer privacy act (CCPA) but also ensure the fairness of data monetization transactions without the involvement of any middleman [TZLHJS17]. This is in stark contrast with the opaque business model of the existing internet economy where giant internet companies absorb all the economic benefits of personal data monetization. Our framework will let individuals regain control of their private data. +The substrate module will specify the types of computation the data purchaser is allowed to perform over the ciphertext. Since the same computation result could be of different values to different data purchasers, automatic payment based on substrate module could be used to enforce sophisticated pricing models to guarantee the maximum economic return for the data owner. + +A publicly verifiable substrate module would not only help with the transparent enforcement of various privacy regulations such as General data protection regulation (GDPR) or California consumer privacy act (CCPA) but also ensure the fairness of data monetization transactions without the involvement of any middleman [TZLHJS17]. This is in stark contrast with the opaque business model of the existing internet economy where giant internet companies absorb all the economic benefits of personal data monetization. Our framework will let individuals regain control of their private data. We all know the slogan “Data is the new oil”. According to alliedmarketresearch.com, the global data monetization market size was valued at $44869 in 2016, and is projected to reach at $370969 million by 2023, growing at a CAGR of 35.4% from 2017 to 2023. Even by capturing a small piece of this market, it would bring enormous economic benefits to the Polkadot ecosystem. -A second-layer fine-grained data monetization framework will also greatly expand the Polkadot community through attracting not only privacy-conscious users but also business partners hunger for high-quality data such as research institutes, hospitals, traditional financial institutes, etc. +A second-layer fine-grained data monetization framework will also greatly expand the Polkadot community through attracting not only privacy-conscious users but also business partners hunger for high-quality data such as research institutes, hospitals, traditional financial institutes, etc. There are three relevant projects: the first one is perhaps the Enigma project, a privacy protocol that enables the creation of decentralized applications that guarantee privacy. The protocol Enigma bases on is secure multi-party computation (MPC). The second one, Insights Network is a data exchange based on combining blockchain technology, substrate module, and MPC. It is based on the EOS blockchain and a custom MPC system. The third one, NuCypher is a cryptographic infrastructure for privacy-preserving applications. Its main technology is threshold proxy re-encryption and fully homomorphic encryption. None of these second-layer protocols are built for the Polkadot ecosystem. -There are several different ways of implementing an MPC protocol: threshold homomorphic encryption, garbled circuit, and secret sharing. The general idea of MPC is to outsource private data (either in the form of secret shares or homomorphic encryption) to a few separate computing parties so that they can perform confidential computation over the encrypted data. Directly applying MPC to fine-grained personal data monetization is problematic in the sense that once the data is outsourced, the data owner does not exert any control over what type of computation can be performed by the computing party. In other words, individual privacy is now at the mercy of these computing parties, which is against the human-centric ethos of fine-grained personal data monetization, where the access control policy should be defined by the data owner and enforced by the algorithm. On the other hand, functional encryption was specifically proposed and tailored for enforcing fine-grained access control over encrypted data. By allowing the data owner to define the access control policy, the owner has full control over what type of access the data purchaser can have over the encrypted personal data. The only decryption result the data purchaser will be able to retrieve is the predefined function evaluation. +There are several different ways of implementing an MPC protocol: threshold homomorphic encryption, garbled circuit, and secret sharing. The general idea of MPC is to outsource private data (either in the form of secret shares or homomorphic encryption) to a few separate computing parties so that they can perform confidential computation over the encrypted data. Directly applying MPC to fine-grained personal data monetization is problematic in the sense that once the data is outsourced, the data owner does not exert any control over what type of computation can be performed by the computing party. In other words, individual privacy is now at the mercy of these computing parties, which is against the human-centric ethos of fine-grained personal data monetization, where the access control policy should be defined by the data owner and enforced by the algorithm. On the other hand, functional encryption was specifically proposed and tailored for enforcing fine-grained access control over encrypted data. By allowing the data owner to define the access control policy, the owner has full control over what type of access the data purchaser can have over the encrypted personal data. The only decryption result the data purchaser will be able to retrieve is the predefined function evaluation. ## Team :busts_in_silhouette: + ### Team Members -* David Spade - Full-stack Software Engineer -* Kevin Hsu - Data Scientist -* Dylan Dewdney - Marketing Advisor -* Beni Issembert - Strategy Advisor +- David Spade - Full-stack Software Engineer +- Kevin Hsu - Data Scientist +- Dylan Dewdney - Marketing Advisor +- Beni Issembert - Strategy Advisor ### Team Website -* http://rubyprotocol.com/ +- http://rubyprotocol.com/ ### Legal Structure -* Ruby Technology Ltd. is a company registered in the Cayman Islands. + +- Ruby Technology Ltd. is a company registered in the Cayman Islands. ### Team Experience + **David Spade** David Spade graduated from the University of Nottingham. He is a full-stack developer with 8 years of experience in software development. David also has deep knowledge in zero-knowledge algorithms and he is an expert in data science. @@ -116,44 +123,53 @@ Beni Issembert is a former Beam Privacy CMO, and currently works as Concordium C Dylan Dewdney is a longtime crypto enthusiast (2011). In 2017 he co-founded Harbour DAO, which became an open-standard set of tools for building governance structures and voting mechanisms on ERC-20. Later, as Chief Evangelist of Beam and Head of Growth for AdEx, he was a key part of their GTM and general growth strategies. Dylan is a respected peer among many different projects and areas of business.Dylan is also the project lead and CEO of DeData project Kylin Network. ### Team Code Repos -* https://github.com/Ruby-Protocol + +- https://github.com/Ruby-Protocol ### Team Linkedin Profiles -* www.linkedin.com/in/dylan-dewdney -* www.linkedin.com/in/beniissembert -* www.linkedin.com/in/yingkaixu + +- www.linkedin.com/in/dylan-dewdney + +- www.linkedin.com/in/beniissembert +- www.linkedin.com/in/yingkaixu ## Development Roadmap :nut_and_bolt: + ### Overview -* **Total Estimated Duration:** 2 months -* **Full-time equivalent (FTE):** 3 FTE -* **Total Costs:** 30,000 DAI + +- **Total Estimated Duration:** 2 months + +- **Full-time equivalent (FTE):** 3 FTE +- **Total Costs:** 30,000 DAI #### Milestone 1 — Implement Cryptographic Modules -* **Estimated Duration:** 5 months -* **FTE:** 1 -* **Costs:** 10K DAI -The main deliverable of this milestone includes: -* A cryptographic library written in Rust that implements the inner product functional encryption and quadratic polynomial functional encryption. +- **Estimated Duration:** 5 months + +- **FTE:** 1 +- **Costs:** 10K DAI + +The main deliverable of this milestone includes: + +- A cryptographic library written in Rust that implements the inner product functional encryption and quadratic polynomial functional encryption. -* A substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. +- A substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. | **Number** | **Deliverable** | **Specification** | | ---------- | ------------------------------------- | ------------------------------------------------------------ | | 0a. | License | Apache License 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | -| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | -| 0d. | Article/Tutorial | We will publish a medium article that explains the functionality of the proposed cryptographic library and substrate pallet delivered in this milestone. +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0d. | Article/Tutorial | We will publish a medium article that explains the functionality of the proposed cryptographic library and substrate pallet delivered in this milestone. | 1. | Cryptographic modules | We will implement the cryptographic modules including inner product functional encryption and quadratic polynomial functional encryption [MSHBM2019] and the associated zero-knowledge proof [ZeroPool]. The cryptographic modules will be written in Rust and modified from the [rust version](https://github.com/dev0x1/functional-encryption-schemes) of [CiFEr library](https://github.com/fentec-project/CiFEr). We will build privacy-preserving classification and neural networks based on these modules. We will also implement a substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key. | | 2. | Benchmark | Perform unit tests on the individual algorithms to ensure their safety. Benchmark on the gas cost and throughput of the proposed module. | | 3. | Docker | We will provide a dockerfile to demonstrate the usage of our modules. | #### Milestone 2 —— Client Implementation and Integration -* **Estimated Duration:** 1 month -* **FTE:** 2 -* **Costs:** 20K DAI +- **Estimated Duration:** 1 month +- **FTE:** 2 +- **Costs:** 20K DAI The main deliverable of the milestone is the client that can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms. @@ -161,17 +177,19 @@ The main deliverable of the milestone is the client that can trigger the aforeme | ---------- | ------------------------------------- | ------------------------------------------------------------ | | 0a. | License | Apache License 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works. | -| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Article/Tutorial | We will publish a medium article that explains the functionality of the proposed client and UI delivered in this milestone. | 1. | Client modules | We will implement the client to support the key distribution and decryption of the functional encryption scheme [MSHBM2019]. The client will also generate the transaction that can trigger the aforementioned cryptographic modules and the micropayment scheme [MDJM2019], such as the encrypted functional key and zero-knowledge proof. We will provide a basic UI to take inputs from the users for all these algorithms and receive the outputs. More specifically, the UI will enable the data owner to input the raw data to generate the signed ciphertext and upload it to the cloud server. The UI will also allow the data purchaser to retrieve the functional key from the key authority and the ciphertext from the cloud and then perform the decryption. The UI will also register a qualified data source and allow a data owner to join the data monetization program when he/she meets the data source and the data owners to request a signature from a registered source, which will then be verified on-chain. Finally, it will also allow these entities to interact with the substrate module with the inputs and outputs defined in our architecture. | | 2. | Benchmark | Perform unit tests on the individual algorithms to ensure their safety. Benchmark on the latency and usability of the proposed client functionalities. | | 3. | Docker | We will provide a dockerfile to demonstrate the usage of our modules. | ### Community Engagement -* **Bounty Program for General Community:** We will reward users who contribute positively to community building and content creation through an Ambassador Program. The community management team will be available 24/7 to answer questions. -* **Incentive Program for Data Monetization:** After the main functions are completed, we will provide incentives for users to monetize their data on our platform. This is an encouragement for users to provide the data and purchase the data. -* **Parachain Loan Offering Campaign:** We may hold a Parachain Loan Offering and reward users for helping our auction with Ruby Protocol tokens. -* **Affiliated Program of Cryptographic Infrastructure:** It is proven effective for user growth and can be integrated into Ruby’s cryptographic infrastructure. + +- **Bounty Program for General Community:** We will reward users who contribute positively to community building and content creation through an Ambassador Program. The community management team will be available 24/7 to answer questions. + +- **Incentive Program for Data Monetization:** After the main functions are completed, we will provide incentives for users to monetize their data on our platform. This is an encouragement for users to provide the data and purchase the data. +- **Parachain Loan Offering Campaign:** We may hold a Parachain Loan Offering and reward users for helping our auction with Ruby Protocol tokens. +- **Affiliated Program of Cryptographic Infrastructure:** It is proven effective for user growth and can be integrated into Ruby’s cryptographic infrastructure. ## Future Plans @@ -184,6 +202,7 @@ In phase 2, our goal is to deliver the micropayment scheme and enable the users Finally, our goal is to provide an essential open API and SDK from a high-level perspective with the above tools, fully powering the data monetization framework on Polkadot. ## Additional Information :heavy_plus_sign: + ### Reference [GPSW06] Goyal, V., Pandey, O., Sahai, A., & Waters, B. (2006, October). Attribute-based encryption for fine-grained access control of encrypted data. In Proceedings of the 13th ACM conference on Computer and communications security (pp. 89-98). @@ -192,11 +211,11 @@ Finally, our goal is to provide an essential open API and SDK from a high-level [GKPVZ13] Goldwasser, S., Kalai, Y., Popa, R. A., Vaikuntanathan, V., & Zeldovich, N. (2013, June). Reusable garbled circuits and succinct functional encryption. In Proceedings of the forty-fifth annual ACM symposium on Theory of computing (pp. 555-564). -[ALS2016] Agrawal, S., Libert, B., Stehle, D.: Fully secure functional encryption for inner products, from standard assumptions. In: Annual International Cryptology Conference. pp. 333{362. Springer (2016). +[ALS2016] Agrawal, S., Libert, B., Stehle, D.: Fully secure functional encryption for inner products, from standard assumptions. In: Annual International Cryptology Conference. pp. 333-362. Springer (2016). [B2017] Bourse, F. (2017). Functional encryption for inner-product evaluations (Doctoral dissertation). -[B2018] Vitalik Buterin, +[B2018] Vitalik Buterin, https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477, 2018. @@ -222,12 +241,4 @@ https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-t [SC2017] Agrawal, Shashank, and Melissa Chase. "Simplifying design and analysis of complex predicate encryption schemes." Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, Cham, 2017. [SGP2018] Sans, E.D., Gay, R., Pointcheval, D.: Reading in the dark: Classifying encrypted digits with functional encryption. IACR Cryptology ePrint Archive 2018, 206, (2018). -[TZLHJS2017] Florian Tramer, Fan Zhang, Huang Lin, Jean-Pierre Hubaux, Ari Juels, and Elaine Shi. ”Sealed-glass proofs: Using transparent enclaves to prove and sell knowledge.” In Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, pp. 19-34. IEEE, 2017. - - - - - - - - +[TZLHJS2017] Florian Tramer, Fan Zhang, Huang Lin, Jean-Pierre Hubaux, Ari Juels, and Elaine Shi. ”Sealed-glass proofs: Using transparent enclaves to prove and sell knowledge.” In Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, pp. 19-34. IEEE, 2017. diff --git a/applications/SEOR-code-less-smart-contract-platform.md b/applications/SEOR-code-less-smart-contract-platform.md index 7cfd500a4be..ec2a9d6c9b2 100644 --- a/applications/SEOR-code-less-smart-contract-platform.md +++ b/applications/SEOR-code-less-smart-contract-platform.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# SEOR code-less smart contract platform -* **Project Name:** SEOR code-less smart contract platform * **Team Name:** SEOR * **Payment Address:** 0x573e932F79a8846a058032454Ee7Fd7C6df7Dc41 * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/205#issuecomment-1168462194) @@ -135,7 +134,7 @@ https://github.com/SealSC | 1. | License | Apache License 2.0 | | 2. | SDK code repository | A git repository of SEOR-JS-SDK implemented using TypeScript. The SDK uses a unified interface to support the interaction between front-end DApp and substrate nodes, Ethereum nodes and other blockchain nodes of different architectures, allowing developers to access different chains with minimal changes without modifying the logic. | | 3. | Testing Guide | The SDK with have enough unit-test coverage(min 80%) to ensure functional integrity and robustness. All of the test cases, test codes and test guides will be added to the repository. | -| 4. | Multi-Chain Support | Support interactions with multiple public chains, including Polkadot, Ethereum, Ontology, EOS. At least the following wallets will be supported: [polkadot{.js} extension](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd), [MetaMask extension](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn), [imToken](https://token.im/), [ONTO](https://www.onto.app/). We will provide several web page to proof the chains and wallets was supported by this SDK. | +| 4. | Multi-Chain Support | Support interactions with multiple public chains, including Polkadot, Ethereum, Ontology, EOS. At least the following wallets will be supported: [polkadot\{.js} extension](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd), [MetaMask extension](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn), [imToken](https://token.im/), [ONTO](https://www.onto.app/). We will provide several web page to proof the chains and wallets was supported by this SDK. | | 5. | Documentation | The SERO-JS-SDK tutorial and documentation guide users how to quickly get started using it, and provide as detailed use cases as possible. These documents will be added to the git repository, and a pdf file download link will be provided on the project website. | @@ -149,7 +148,7 @@ https://github.com/SealSC | 1. | License | Apache License 2.0 | | 2. | Code-less smart contract platform DApp | A code-less smart contract platform DApp will be deployed under a second-level domain name of this project. The DApp's UI part will be implement by VUE, and it will have a custom designed UI to uniform different chain's interface. The interactive with these chains will be supported by SEOR-JS-SDK. Through this DApp, users can deploy the contract implemented in Milestone 1 without coding to the parachains supporting smart contracts or directly to Ethereum, and contract interaction can be carried out in the platform powered by SEOR-JS-SDK. | | 3. | Testing Guide | The DApp with have enough unit-test coverage (min 80%) to ensure functional integrity and robustness. All of the test cases, test codes and test guides will be added to the repository. | -| 4. | Multi-Chain Support | The DApp will support at least 4 public chains: Polkadot, Ethereum, Ontology and EOS. Users can interactive inside the DApp with those chains through different wallets which supported by SERO-JS-SDK: [polkadot{.js} extension](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd), [MetaMask extension](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn), [imToken](https://token.im/), [ONTO](https://www.onto.app/) | +| 4. | Multi-Chain Support | The DApp will support at least 4 public chains: Polkadot, Ethereum, Ontology and EOS. Users can interactive inside the DApp with those chains through different wallets which supported by SERO-JS-SDK: [polkadot\{.js} extension](https://chrome.google.com/webstore/detail/polkadot%7Bjs%7D-extension/mopnmbcafieddcagagdcbnhejhlodfdd), [MetaMask extension](https://chrome.google.com/webstore/detail/metamask/nkbihfbeogaeaoehlefnkodbefgpgknn), [imToken](https://token.im/), [ONTO](https://www.onto.app/) | | 5. | DApp tutorial | Provide a detailed tutorial of DApp so that users can learn about platform functions through this tutorial, and can use the platform for contract deployment and interaction. | ## Future Plans diff --git a/applications/SaaS3.md b/applications/SaaS3.md index ee0de6ff0e1..15d592e7b76 100644 --- a/applications/SaaS3.md +++ b/applications/SaaS3.md @@ -1,186 +1,185 @@ -# W3F Grant Proposal +# SaaS3 -> This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. - -- **Project Name:** SaaS3 - **Team Name:** SaaS3 Lab -- **Payment Address(USDT):** 0x8341e551B0AE5E5905C20A112b123b5F797612f3 -- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Payment Address(USDT):** 5Fv5fgxcWkRhddCwtsZbQt8JGKaezLorwLkkS6y2TuJ1wFs1 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 ## Project Overview :page_facing_up: - ### Overview -#### Dilemma of web3 Ecosystem - With functionalities yet to become full-fledged, Web3.0 applications need a rethink of development stacks. -For instance, most of the web2 projects and dependencies are based on Java, C++, PHP, etc., while web3 requires another totally different technical stacks such as Solidity, Motoku, or Substrate on EVM / WASM which hinders web2 developers to build web3 applications. + +**Summary: SaaS3 is a protocol in layer2 that is highly scalable, crypto incentivized, and results in a solution that can serve as a decentralized APIs (dAPI) middleware to provide off-chain services to blockchain smart contracts.** + +#### Brief Introduction + +**Background** + +Dilemma of web3 Ecosystem - With functionalities yet to become full-fledged, Web3.0 applications need a rethink of development stacks. For instance, most of the web2 projects and dependencies are based on Java, C++, PHP, etc., while web3 requires another totally different technical stacks such as Solidity, Motoku, or Substrate on EVM / WASM which hinders web2 developers to build web3 applications. ![image](https://user-images.githubusercontent.com/95557343/157393726-c22c47d2-a4d0-4335-b890-29d6fad4417c.png) +**Our solution - SaaS3 Oracle** -SaaS3 project aims to deliver a fully decentralized software as a service (SaaS) network with highly scalable, crypto token incentivized and results in a solution that can serve as the application interface (API) layer for web3. -SaaS3 is devoted to transforming traditional web2 API to web3 dAPI by decentralized docker runtime (dRuntime). -Particularly, regardless of development stack differences, Linux-based Web2 APIs can be deployed on our platform for providing web3 services by decentralized APIs (dAPI). -Essentially, SaaS3 is an off-chain scaling technique of layer-2 which utilizes cheap off-chain docker computation to replace high-priced on-chain WASM / EVM runtime, while still remaining computation decentralization by delegated proof of stake (DPoS) consensus and on-chain zero knowledge proof. -Therefore, such layer-2 off-chain scaling is not only for computation price but technical development stacks compatible. -The SaaS3 project aims to decentralize computational providers and mint income-NFT to earn profits. -The API creators could earn an income fee by holding those iNFT or selling them on NFT marketplace. -As a result, the SaaS3 project will bridge web2 APIs to web3 dAPIs to flourish web3 ecosystem and achieve creator economy in a decentralized and trust-minimized way. -This grant will allow us to develop several pallets to implement a parachain with substrate on Polkadot / Kusama. - -SaaS3 as a part of Polkadot / Kusama / web 3 Ecosystem and has the following properties: - - - Bridge - Monetize abundant web2 projects as decentralized web3 services in a very short time with extremely cheap cost. - - No Middleman - Cheap fee for dAPI users or Dapp developers compare with centralized SaaS products. - - Security - Improve the security for a system by PoS consensus and zero knowledge proof for miner network. Web3 dAPI are backed by token stakers (DPoS) with a reward and punishment mechanism. - - Reliability - Strengthen robustness for dAPI by computation decentralization and dRuntime redundancy of miners. - - Green - Save energy and reduce the cost by making use of spare computation resources for API computation. - -### Protocol Details +SaaS3 aims to deliver a highly scalable, crypto token incentivized and fully decentralized software as a service (SaaS) network which results in a solution that allows anyone to define and deploy customized oracles according to their Dapp needs. SaaS3 is devoted to transforming traditional web2 API to web3 dAPI. -#### Architecture +Essentially, SaaS3 is an TEE powered oracle infrastructure that allows anyone to define and deploy custom oracles according to their Dapp requirements. SaaS3 utilizes TEE technologies, while still enabling decentralization, trustless and secure computation by the secure hardware guarantee of Intel SGX chipset designs and by delegated proof of stake (DPoS) consensus. + +Therefore, such an infrastructure is not only for oracles that provide data feeds but also any type of computation which requires safe exchange of data. + +Examples: -![image](https://user-images.githubusercontent.com/95557343/159788632-250f04b6-b2b9-42c5-9927-6e4487aea8ef.png) +1. Any data feed: + - Price of assets (ERC20/NFTs) on CEX and DEX. + - Random Numbers + - Weather reports, price of rent of an apartment, supply chain data, FIFA match results... +2. Cross-chain data: + - Bridges and cross-chain relayers +3. Computation + - Decentralized off-chain computation to enable truly decentralized metaverses and games +4. Any Dapp that requires trust: + - Custodian account managed by TEE for GameFi users that allows them to interact with the blockchain with only web2 api requests. +SaaS3 enables Dapps to become as versatile as any other web2 application available today on the internet. As a result, the SaaS3 project will bridge web2 APIs to web3 dAPIs to flourish web3 ecosystem and achieve creator economy in a decentralized and trust-minimized way. This grant will allow us to develop several ink! smart contracts and a pallet for DAO management. -Decentralized docker runtime (dRuntime) is built on miner network which aims to execute dAPIs. Those dAPIs is created by API creators as a result of development labor. Computational node targets to setup the dRuntime, or better known as the 'miner', namely the party that performs the computational tasks. They are hereafter referred to as 'nodes' or 'miners'. The Dapp developer is the dAPI user, who sends requests and pays to access the dAPI. Their actions are detailed below. +#### Integration into Polkadot / Kusama - - To access a web3 dAPI, users pay $SA3 tokens to nodes as the Gas fee and to software creators as the royalty fee. +- We planned to developed a parachain on Polkadot as SaaS3 DAO multichain governance centers. +- The major component dRuntime will be implemented in ink!. https://github.com/SaaS3-Foundation/dRuntime-fat - - The node(s) are rewarded to execute dAPIs with dRuntime on their equipments. Importantly, each miner can run multiple dAPIs with dRuntime cache (dCache) to maximize the throughput. +- Collaboration with Phala Network: We have partnered up with Phala Network which is a prominent parachain on the Polkadot ecosystem who will be providing SaaS3 with 15,000+ active TEE miners to enable trustless, permissionless and secure computation for our oracle infrastructure. - - The Creator receives the royalty fee as the reward for their commitment to the docker development; they are the author of Web2 API codes. +#### Team Motivation -![image](https://user-images.githubusercontent.com/95557343/159788719-f6fb785d-65ce-4f7c-a3cb-5b0226708895.png) +Our team has rich experience in web3 ecosystem, and we are dedicated to achieve secure and decentralized oracles. +### Protocol Details + +#### Mockups/designs -##### Security & Off-chain Miner Consensus +The following figures show UI design of SaaS3: -- Miner security - To qualify, a miner or node is required to stake a particular amount of tokens as collateral (POS). Each request for API will trigger an on-chain zero-knowledge proof check (zkc), which determines whether the node is rewarded or punished. +- Marketplace: explore open oracles and their details. + - Marketplace-bg1@2x + - Marketplace2@2x -- API security - Similar to API3 insurance, API security is achieved via Delegation Proof of Staking (DPoS). Particularly, the API creator is required to stake an amount of tokens at the time of submitting the dAPI deployment. The amount is set at a default value in their first submission and is adjusted in proportion to the service income. Besides, the token holders are able to stake on the dAPIs as a collateral and share profits with API creator. The mechanism is established following the same vein of the concepts in Polkadot / Kusama, including staking, nomination, and validation. - -The process described above establishes a de facto safeguard mechanism, sheltering dAPI users from potential malfunctions of the computational node or the API service, and when available providing remedies in compensation. +- Oracles deployment: deploy oracles within few clicks. + - Deploy Oracles@2x + - Deploy Oracles-10@2x -##### Collateral and Sue Claims -In the case of a malfunction, the user detects the misperformance and assesses the damages and losses, and is able to lodge a sue claim published on the Court DAO. In supplement, the staked tokens or collaterals are 'locked' for a period, a mechanism to discourage stakers from 'front-running claims', i.e. withdrawing the staked token as soon as a miner or service malfunctions to evade claims. On the other hand, the litigant is required to stake funds to be able to make a claim, which elevates the cost of abuse. The Court DAO deliberates on the sue claim and decides whether a remedy should be made to the victimized dAPI user. Once a claim is passed in Court DAO, the amount of tokens as has been claimed will be transferred to the litigant in compensation. +- User Profile: view user information, wallet information, stake information, and deployed oracles. + - Profile-planA1@2x -The same mechanism also applies to the punishment meted out for the node(s) that malfunctioned with on-chain zkc. Such a reward-and-punishment mechanism encourages nodes to act in good faith and better service quality. Hence, a much lower risk of potential cyber threats such as the Sybil attack. -##### Implementation Layers +#### Technology Stack -![image](https://user-images.githubusercontent.com/95557343/155807244-b10e6228-edf9-479a-add9-b4c347f62e2e.png) +- Substrate +- TEE +- gRPC +- Rust +- ink! -#### Technologies -1. Substrate -2. Docker -3. Virtualization Technology -4. Deep learning frameworks -5. libp2p -6. IPFS / ARWeave -7. gRPC -8. Rust -9. Substrate front-end template -10. Go +#### SaaS3 Protocol +SaaS3 protocol constructs a permissionless oracle network (PoN) to eliminate centralized computation resources to deliver developers the ability to create their customizable oracle (dAPI) by one-click permissionlessly and hostlessly. -#### Components +**Permissionless Oracle Network (PoN)** -1. **Location Proof of Stake (LPoS) with zkc for Miners** -Regarding the miner network, we deploy on-chain zero knowledge check (zkc) and adopt a location-based optimization for PoS consensus, thus improving the network throughput for off-chain dRuntime execution. Specifically, when a dAPI user sends a request, a list of miner candidates will be generated, consisting of 10 nodes in the closest locations, (e.g., determined by network latency) which are determined by network latency. Meanwhile, since all nodes are required to have staked a amount of tokens, nodes are ranked in a list of, for example, 100 according to the staked amount. 3 miners has to be among the leading token stake and the ten nearest to qualify for executing the request and receiving the rewards, while the on-chain zero-knowledge check (zkc) is carried out. Admittedly, the network may to some degree hurt tolerable security. Nevertheless, the dAPI user will be able to access not just at low net-latency but also backed by the PoS consensus with zkc (for more about zkc, please refer to 7 or 9). It should also be noted that node congestion is mitigated en passant. +In PoN, four roles are involved: creator, miner, staker, and requester, and each role should accommodate SaaS3 protocol to stake and contribute to maintaining the high-quality services as shown in the following figure. +Screenshot 2022-11-12 at 4 41 30 PM - +- **Creator** is the role of submitting dRuntime to create an oracle (dAPI) service, who can be any kind of off-chain service providers such as crypto exchanges, events organizers, or software developer. +- **Staker** is anyone participating in the delegated proof of stake (DPoS) mechanism. +- **Miner** acts as the computational worker to execute dRuntime on the hardware. TEE workers in Phala Network will be adopted in SaaS3 ecosystem to undertake this critical mission. +- **Requester** calls the SaaS3 protocol to request off-chain services such as particular data feeds or off-chain computation results. -2. **dRuntime** -dRuntime refers to a decentralized docker runtime which execute dAPIs in a network of distributed computing resources. It is essentially an off-chain technique to scaling up computation for on-chain runtime, such as WASM or EVM in Polkadot or Ethereum networks. +**Decentralized Serverless Runtime (dRuntime)** -3. **dCache** -dRuntime cache is a 3-level caching mechanism to guarantee high performance and large throughput for dRuntime. +In SaaS3, dRuntime (Decentralized Serverless Runtime) is a concept against centralized deployed runtimes which are centralized on cloud computing servers. dRuntime can be deployed on miner networks in a decentralized way by SaaS3 oracle launchpad. The launchpad is a Dapp for oracle creators to create their oracle with one click. Particularly, the creators should integrate the dAPI programs and settings into the dRuntime on the launchpad. Therefore, one oracle can be executed by multiple miners to achieve off-chain services instead of trusting an off-chain single point. - +There are four phases for dRuntime execution: -4. **SaaSDAO** -SaaSDAO refers to the decentralized autonomous organization charged with governance duties. - +1. **Request**: The Dapp smart contracts will call the protocol contract to request a specific off-chain service. The protocol contract will record the request specifications in blockchain event logs. +2. **Filtering**: For each on-chain request, the protocol will generate a lightweight PoW (LPoW) task. The miners will compete to win the execution permissions by solving the LPoW task. The fastest 3 miners will win the execution permissions to run the API. Besides, the winners should be in the top-100 stake list, in other words, they should have a good amount of token stakes. +3. **Execution**: The 3 winners in the last phase execute the corresponding API to retrieve the off-chain services. +4. **3-zkc**: An on-chain verification is performed with three miners’ responses to aggregate the final output with the reward/slash on miner stakes. -5. **iNFT** -iNFT refers to a tradable income NFT that is minted when an API creator submits a docker image to create a dAPI. iNFT allows the API creator to earn royalty fee. -6. **Miner Network** -The miner network is implemented by pallet-miner and consists of all the providers of computational capabilities. The network offer decentralized APIs which undertakes to execute containers to reply DeResponse for user's DeRequest. All docker images can be deployed on each miner. Thus, other nodes are called in replacement should any node break down. The 'redundancy' of computing nodes, which is at the miner-level, helps the SaaS3 maintain its decentralization features and remain robust. -7. **On-chain 3-person zero knowledge proof check (3-zkc) and rewards** -Each dAPI call will be executed by 3 miners. Therefore, the hash values generated following the three responses will be compared against each other for agreement. The 3-zkc is performed enabled by a callable, on-chain pallet-function. There are multiple scenarios, as follows. - - The three hash values are in agreement. No one will being slashed. - - Only two values are in agreement, the check still gains approval. Another miner is found inconsistent and will be slashed on its token stake. - - There is no agreement among the three nodes. In this case, the API call returns failure. The gas fee is nonetheless consumed and has no refunds. No party will face slash or claim reward, as neither miner malfunctions nor dAPI bugs can be found attributable. However, the failure-logs are recorded on on-chain storage. The user could raise an issue to the creator to push for a new docker, or lodge a sue claim on Court DAO as a query for potential compensation from miners / creators. For more details, please refer to 9. 3-zkcg. -8. **Court DAO** -At Court DAO, the dAPI user can pay a fee for sue claims and, subject to the court's ruling, may claim compensation from miners / creators on SaaS3 DAO on grounds of any dAPI failure. To supplement the on-chain failure logs, the user is required to provide the details regarding the failure case, such as the input data and the version of the failed API (docker image version). The Jury consists of top 101 largest staked API creators who are open source developers and active on DAO events. Members of the Jury can download the same version docker image and retest the failure case to investigate the failure cause. The on-chain failure log is available for jury members. +#### Architecture - Jury will have the following options given the on-chain log records and local test results. +SaaS3 architecture - - Reject - The user's sue claim is rejected, with no compensation, and the sue fee will not be refunded. Such a ruling may be on the grounds such as forged evidence and unreasonable amount of claims. Terms and conditions and regulations of SaaSDAO apply. - - Approve - - Miner malfunction: - - Which miners should be slashed. (This is multiple choices refer to on-chain log): - - Miner1, Miner2, or Miner3 - - Slash the dAPI in terms of drawbacks or bugs. - + - Target Chain: SaaS3 protocol will be deployed on multiple blockchains, such as Polkadot and Kusama. + - Dapp: decentralized applications which adopt SaaS3 oracle. + - SaaS3 Protocol: a proxy smart contract which accept requests from Dapp and push them to Phat Rollup Anchor. + - Phat Rollup Anchor: a smart contract built by Phala Network. It performs offchain rollup and commuicates to a phat contract dRuntime. Repo: https://github.com/Phala-Network/phat-offchain-rollup + - SaaS3 Launchpad: a web-based Dapp which allows oracle creators to one-click launch their customizable oracle hostlessly and permissionlessly. By using Factory contract, oracle creators can deploy dRuntime phat contract easily. + - Phat contract: the innovative programming model enabling off-chain computation which is created by Phala Network. It’s also known as Fat Contract as a practice of the "Fat Protocol and Thin Application" concept, and for its rich functionalities compared with existing smart contracts. Phat Contract uses Rust-based ink! language. + + - Offchain Scheduler: a phat contract built by Phala Network. + - dRuntime: dRuntime (Decentralized Serverless Runtime) is a concept against centralized deployed runtimes which are centralized on cloud Computing servers. It can be deployed on miner networks in a decentralized way by SaaS3 oracle launchpad. + - Phala Workers: are the TEE computation nodes with intel SGX chips which provide a hardware-encrypted sandbox for program executions with privacy-preserving and trustful computations. + - Web2: includes all web2 services which provide API services, such as pricing reporting, event news, graph rendering and deep learning. -9. **3-zkc and gas calculation algorithm (3-zkcg)** +#### Private Oracle -We will provide a protocol / software which is similar with [AWS Lambda API Pricing](https://aws.amazon.com/lambda/pricing/) for miner, but replace dollar unit with gas. In SaaS3, miners should monitor each container's resource usage by our software to calculate gas usage i.e., `gas_used` for once dAPI call. `rewards=gas_used*gas_price` gas_used is defined by following process with 3-zkc. Here, we illustrate the algorithm to show the procedure, a user request with `gas_limit` is sent to three miners `m1,m2,m3` at time `t=0` with user-set maximum timeout `Tmax`, there will be following scenarios: - - If after timeout `Tmax`, no response is received, go to the failure state. - - Else, got `m1` response `r1` with reported gas `g1` at time `t1`, reset timeout `Tmax=max(2*t1, Tmax)`. - - If after timeout `Tmax`, go to failure state. - - Else, got `m2` response `r2` with reported gas `g2` at time `t2`, zkc will be conducted to confirm whether `r1=r2` - - `r1=r2` return `r1` to user and distribute `rewards=min(g1,g2) * gas_price` to `m1` with `(1-g1/(g1+g2)) * rewards` and to `m2` with `(1-g2/(g1+g2))*rewards` which means the lower `gas report`, the more rewards. - - `r1!=r2` reset timeout `Tmax=max(2*t2, Tmax)` - - If after timeout `Tmax`, go to failure state. - - Else, got `m3` response `r3` with reported gas `g3` at time `t3`, zkc will be conducted to confirm whether `r3=r1` or `r3=r2` - - If `r1!=r2!=r3`, go to failure state. - - Else, two conditions - - `r3=r1`, return `r1` to user and distribute `rewards=min(g1, g3) * gas_price` to `m1` with `(1-g1/(g1+g3)) * rewards` and to `m3` with `(1-g3/(g1+g3))*rewards`. `m2` will be slashed. - - `r3=r2`, return `r2` to user and distribute `rewards=min(g2, g3) * gas_price` to `m2` with `(1-g2/(g2+g3)) * rewards` and to `m3` with `(1-g3/(g2+g3))*rewards`. `m1` will be slashed. - - Failure state: reply user `error: dAPI fail` and charge gas fee as `gas_mean * gas_price`, where `gas_mean` is the average gas for that dAPI in the history. Neither three miners will be slashed, since in such case, it hard to determine whether the dAPI has bugs. The user could raise an issue/sue to Creator/CourtDAO to acquire compensation based on above on-chain records. If the miners notice some weird slashes with on-chain evidence, miners could raise sue to CourtDAO with their proof (e.g., give an IPFS docker image path which is the same version as creator submitted) to acquire claims and slash dAPI with acceptance from Court DAO. +Phala network is exploited in SaaS3 as a decentralized computational infrastructure with hardware-encrypted TEE chips. Trusted Execution Environment (TEE) is a special area in some processors that provides a higher level of security including isolated execution, code integration, and state confidentiality. Thus, the oracle creators can easily store the API key or private data inside the fat contract which cannot be leaked out or be visible to miner operators. -a0e9fb71f04ea16161f09ca17048e72 +Private oracle is a particular kind of dAPI that only can be requested by the oracle creators themselves. Regardless of public oracles which only provide public data feeds, there is a large market for private oracles to connect blockchains with private off-chain services. To our knowledge, SaaS3 is the first oracle platform to support private oracle setup with a high-security architecture and one-click fast development. +#### SaaS3 DAO +SaaS3 DAO refers to the decentralized autonomous organization (DAO), a governance body established with a full-fledged mechanism for token economics. +Since the SaaS3 protocol will be deployed on multiple blockchains, each blockchain should have its own SaaS3 DAO. To manage different DAOs among multiple blockchains, SaaS3 will launch a Polkadot crowdloan to register a dedicated SaaS3 DAO parachain. The following figure demonstrates the multi-DAO structure. -### Game theory Proof for 3-zkc algorithm with Nash Equilibrium Convergence ### +![Multi-DAO Structure](https://user-images.githubusercontent.com/20609724/205201673-8432c380-2751-48fc-86a0-8bb4d3335e42.png) -Both Miner1,Miner2, and Miner3 will choose loyalty. - +**Treasury** +Each SaaS3 DAO has a treasury to maintain a pool of tokens that come from the commissions of dAPI subscription fee, and malfunction scrutiny and are designated funds for court jury rewards, protocol maintenance, and other DAO events. +DAO treasury receives tokens when: -### Technical Implementation Diagram -We will implement 5 pallets: `pallet-entity`, `pallet-dAPI`, `pallet-DAO`, `pallet-miner`, and `pallet-stake` where `pallet-dAPI` is the core component of the project. +- An oracle malfunctions due to inherent design flaws. +- A miner node malfunctions due to miner dishonesty. +- For each successful fulfillment of a dAPI subscription, the treasury receives a commission from a portion of the subscription fee payable by the user. -![image](https://user-images.githubusercontent.com/95557343/159320880-a6fc9d62-5cc2-457e-9797-11db72edf352.png) +For each court ruling, the treasury sends to the Jury as a reward for their participation in the governance. Since SaaS3 protocol is a multi-chain deployment, SaaS3 DAO parachain on Polkadot has the largest treasury to manage other treasuries among multiple blockchains. +**Court DAO** + +A court as a component of a decentralized autonomous organization has been adopted as a medium of governance to consolidate consensus, justify DAO legitimacy and improve governance. + +On the Court DAO, there is a team of Jury members, consisting of 101 API creators that contribute most to the SaaS3 ecosystem which can be quantized by their API earnings. The court DAO receives the lawsuit from suing actors, composed of users and miners. The Jury members will make a judgment on the lawsuit by voting. If the suing actors win the lawsuit, the entities being accused will be penalized, the suing actor will be compensated for their loss and Jury members will be rewarded for their contribution to the case. + +Court DAO is charged with settling disputes regarding the performance of dAPI to hold dishonest actors accountable. Where there is a dAPI user who experiences a dAPI malfunction and fills a claim at Court DAO for scrutiny, Court DAO commences processing the case. Court DAO is seated by a group of jury members, who receive rewards for rulings. Rulings at Court DAO result in two outcomes; either the party who has filed the claim wins and the liable party has their staked tokens slashed, or the claim is dismissed. ### Ecosystem Fit -- Although web2 applications are highly dependent on centralized libraries and technical stack, they have a potential case of monetization if migrated to web3 as decentralized web3 dAPI through SaaS3 protocol. -- SaaS3 cloud could be a competitive alternative to centralized SaaS / API providers such as [Salesforce](https://appexchange.salesforce.com), [Microsoft Azure](https://docs.microsoft.com/en-us/rest/api/azureml/) and [Google AI](https://cloud.google.com/products/ai). -- SaaS3 brings millions of dAPI/Dapp users, providers of computing resources and users into a harmony and an organic ecosystem, with lowered costs and reliable services. SaaS3 aims to become the world's largest decentralized API platform based on Polkadot / Kusama to provide high-quality dAPIs / Dapps at extremely affordable prices. -- SaaS holds potential for interaction with other parachains of Polkadot / Kusama. SaaS3's dAPIs can also be utilized as computation services for other parachain's specific usage such as AI-related recognition or game-AI algorithms. +- Where and how does your project fit into the ecosystem? -Similar Projects: + - SaaS3 provides a native and secure oracle solution to Dapps, empowering all DeFi projects in Polkadot / Kusama ecosystem. + - SaaS3 holds potential for interaction with other parachains of Polkadot / Kusama such as Phala(Oracle Miner) and Moonbeam(Oracle User). -- **Livepeer** https://livepeer.org/ It provides a video encoding service instead of general web3 SaaS. -- **API3** https://api3.org/ Its dAPI as decentralized oracle to provide off-chain data streaming for smart contracts instead of computation tasks to offer a SaaS in web3. +- Target Audience: Dapp developers and parachain developers. SaaS3 oracle allows them to define and deploy customized oracles according to their Dapp needs. +- What need(s) does your project meet? -SaaS market in Dapp, web3.0, and Metaverse: + - Although web2 applications are highly dependent on centralized libraries and technical stack, they have a potential case of monetization if migrated to web3 as decentralized web3 dAPI through SaaS3 protocol. + - SaaS3 brings millions of Dapp users, providers of computing resources and creators into a harmony and an organic ecosystem, with lowered costs and reliable services. + - SaaS3 facilitates the privacy computation and TEE adoption in web3. -- **Software Services** For example, the softwares on [Salesforce](https://appexchange.salesforce.com), Office365, Grammarly. -- **AI Services** Speech2Text, Voice2Text, Image Recognition, UGC-NFT Recognition, Marketing Analysis, Algorithm Recommendation, Bot-AI, Game-AI, Reinforcement Learning, and Behavior Analysis. +- Compared to similar projects: -### Designs / Mock-ups -![6742e6c196c0ec2354f3e65474c0dd7](https://user-images.githubusercontent.com/95557343/155807321-3d96b3a6-f6c1-4b64-9411-3d75bd7eceb5.png) -![a07096c685597b9faaa8de4bce9956c](https://user-images.githubusercontent.com/95557343/155807345-fd92a0aa-1d5f-44ea-a57a-4f1ec8a4f70c.png) + - In Substrate / Polkadot / Kusama ecosystem: + + - [Kylin Network](https://www.kylin.network/): It offer less secure oracle solution, and its oracle nodes are neither permissionless nor decentralized . + + - In related ecosystems: + - [Chainlink](https://chain.link/): It is not dynamic, and it is hard to create customized oracle. Also, it does not have decentralized computation. + - [API3](https://api3.org/): Permission and centralized host server required. + + Competitor chart ## Team :busts_in_silhouette: @@ -188,7 +187,7 @@ SaaS market in Dapp, web3.0, and Metaverse: ### Team members The core team members are top Ph.Ds in computer science who are technical and experienced. -- **Steven** is a Ph.D. in artificial intelligence and vice president of SaaS3 to build dRuntime on p2p network and financing-related works. Currently, he is an AI researcher and blockchain developer. He has written computer programs since he was 14 and got many hackathon awards in the past. +- **Steven** is a Ph.D. in artificial intelligence and vice president of SaaS3 to build dRuntime on p2p network and financing-related works. Currently, he is an blockchain researcher and blockchain developer. He has written computer programs since he was 14 and got many hackathon awards in the past. - **Rocky** is the CTO of SaaS3 undertakes SaaS3 protocol design. Currently, he is the presidential postdoctoral fellow in NTU and chief scientist in Singapore Smart City Project. Previously, he was an AI researcher at UCB. Besides, he is also a visiting lecture professor of NTU, NUS. He is also the winner of over 10 hackathons. @@ -196,10 +195,7 @@ The core team members are top Ph.Ds in computer science who are technical and ex - **Israel** is the core developer of SaaS3 and undertakes the development of the creator submission network. Besides, he is the CTO of Chapa. He is the founder of Colimo City. Previously, He was the AI researcher in Google Brain, MILA of Turing Award Winner Yoshua Bengio’s Lab. He has 4 years of experience in AI development. -- **Laekshan** was a software engineer in a world-leading company. He is also an expert in IoT -development. He has mined bitcoin since 2015. Therefore, he has a lot of experience in crypto mining and market analysis. - - +- **Tianyi, Song** is the core developer of SaaS3, and a former dev team manager of SkyCloud Co., Ltd. He is an expert in cloud computing development and has a lot of experience in bridging web2 to web3. ### Contact @@ -210,15 +206,17 @@ development. He has mined bitcoin since 2015. Therefore, he has a lot of experie ### Legal Structure - **Registered Address:** 71 Nanyang Dr, NTU Innovation Center, Singapore 638 -- **Registered Legal Entity:** Giant Whales Corporation +- **Registered Legal Entity:** SaaS3 Foundation LTD. ### Team Code Repos -- https://github.com/SaaS3DAO/ -- https://github.com/SaaS3DAO/DeAIMainNet -- https://github.com/SaaS3DAO/non-api-nft -- https://github.com/SaaS3DAO/substrate-node-template -- https://github.com/SaaS3DAO/substrate +- https://github.com/SaaS3-Foundation +- https://github.com/SaaS3-Foundation/dRuntime-fat +- https://github.com/SaaS3-Foundation/druntime-rs +- https://github.com/SaaS3-Foundation/SaaS3-Protocol +- https://github.com/SaaS3-Foundation/abi +- https://github.com/SaaS3-Foundation/autocall +- https://github.com/SaaS3-Foundation/SaaS3-Dapp GitHub accounts of all team members. @@ -229,6 +227,7 @@ GitHub accounts of all team members. - https://github.com/Deslate - https://github.com/kkazuha - https://github.com/hugoycj +- https://github.com/songtianyi ### Team LinkedIn Profiles (if available) @@ -240,78 +239,69 @@ GitHub accounts of all team members. ### Overview -- **Total Estimated Duration:** 6 months -- **Full-Time Equivalent (FTE):** 5 -- **Total Costs:** 45500 USDT - -### Milestone 1 — SaaS3 Documentation, pallet-entity, pallet-service, pallet-stake, - -- **Estimated duration:** 2.5 month -- **FTE:** 4 -- **Costs:** 24000 USD +- **Total Estimated Duration:** 3 months +- **Full-Time Equivalent (FTE):** 2 +- **Total Costs:** 10000 USDT +### Milestone 1 — dRuntime in ink! +- **Estimated duration:** 1 month +- **FTE:** 2 +- **Costs:** 5000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0| -| 0b. | Documentation | Documents containing the description of whole architecture design and technical implementation details for SaaS3 Network. | -| 0c. | Testing Guide | We will provide a full test suite and guide for dAPIs usage for `pallet-dAPI`, token stake for `pallet-stake`. `pallet-entity` will be tested for dAPI usage and payment.| -| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 0e. | Article | We will publish an **article**/workshop that explains (what was done/achieved as part of the grant). (Content, language and medium should reflect our target audience described above.) -| 1. | pallet-entity| [pallet_assets](https://crates.io/crates/pallet-assets) is utilized for implementation with a minor change to fit SaaS3 project. An user and creator both can be implemented as entity. They are same in implementation perspective. | -| | Functions | No public function | -| 2. | pallet-dAPI| `pallet-dAPI` is core implementation of SaaS3 project which is a key middle ware and interacted a lot with other pallets' functions. A dAPI is also a iNFT to indicate the beneficial right for API creator. iNFT related part is implemented based on pallet-uniques. | -| | Functions| 1). `pub fn subscribe_dAPI(eid:u32, iNFT_id:u64, timespan:u256, count:u256) ` dAPI user call this function to pay token to subscribe dAPI.
          2). `pub fn create_dAPI(eid:u32, pid:u32)` Creator's docker image will be deployed as a dAPI.
          3). `pub fn use_dAPI(eid:u32, ip_address:Vec, iNFT_id:u64)` dAPI user call this function to allocate reliable miners to run dAPI.
          4). `fn check_dAPI(eid:u32, iNFT_id:u64)` The function can automatically check whether the dAPI is available for usage.| -| | Storage| `ServiceList get(fn iNFT_list): map hasher(blake2_128_concat) u32 => Vec;`
          `SubscriptionList get(fn subscription_list): map hasher(blake2_128_concat) u32 => Vec;`
          `Usages get(fn get_usages): map hasher(blake2_128_concat) u32 => Vec; `| -| | Struct| `pub struct iNFT`
          `pub struct Subscription`
          `pub struct Usage`| -| 3. | pallet-stake| This pallet implements rewards and slashes related functions for token stakers to stake their tokens to services for DPoS consensus. [pallet-staking](https://crates.io/crates/pallet-staking) will be utilized for initial implementation and we will finely package it into our pallet-stake. | -| | Functions|1). `pub fn stake(eid:u32, sid:u32, credits:u32) ` User call this function to stake their credit to a dAPI as collateral.
          2). `pub fn stake queryStake(eid:u32, sid:u32)` It returns how many tokens is staked on a dAPI for a specific entity.
          3). `pub fn queryTotStake(eid:u32, mid:u32)` It returns the total staked tokens for a dAPI.
          4). `pub fn withdraw(eid:u32, sid:u32, credits:u32) ` Staker call this function to withdraw their tokens from dAPI. | -| | Storage|`MinerCollateral get(fn get_miner_collateral): map hasher(blake2_128_concat) u32 => u32;` | -| 4. | UI & Frontend | This part is implemented by [substrate front-end template](https://github.com/substrate-developer-hub/substrate-front-end-template) The frontend and UI of user-side will be finished in this milestone. | - -### Milestone 2 — Documentation and tutorial for miner and DAO. Development of pallet-miner and pallet-DAO - -- **Estimated Duration:** 3.5 month -- **FTE:** 5 -- **Costs:** 21500 USD +| 0b. | Documentation | We will provide a basic documentation that explains how dRuntime works, and how users can use SaaS3 oracle. | +| 0c. | Testing Guide | We will provide a full test suite and guide for testing SaaS3 oracles. | +| 0d. | Docker | We are not able to provide a Dockerfile, because dRuntime is written in Phat Contract, and it is finally compiled to WASM. | +| 0d. | Article | We will publish an article that explains the whole workflow of SaaS3 protocol. | +| 1. | dRuntime-fat | dRuntime implementation in Phat Contract which is a superset of ink!. | +| | Functions | `pub fn handle_rollup()` Entry point for Phat Rollup Anchor
          `pub fn config(rpc, anchor)` Configure the rollup target.| +| | Structs | `struct Config { rpc, anchor, url, apikey }` | +| | Storage | `pub struct Oracle { owner, config }` | + + +### Milestone 2 — SaaS3 DAO Pallets + +- **Estimated Duration:** 2 months +- **FTE:** 2 +- **Costs:** 5000 USD | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0| -| 0b. | Documentation | We will provide both inline documentation of the code and basic tutorials that explains and guides to four roles: User, Miner, Creator, Stakers respectively with some finely detailed examples. For instance, how to set up machines and mine tokens for miners, or how to propose a decentralized docker image and submit to miner network. | -| 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 for four pallets: pallet-miner and pallet-DAO| -| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 0e. | Article | We will publish an **article**/workshop that explains (what was done/achieved as part of the grant). (Content, language and medium should reflect our target audience described above). | -| 1. | pallet-miner | The pallet implements on-chain related things for miner to compute off-chain docker runtime. The computational power providers or miners in the network provide dAPI which aim to execute docker runtime to reply user's dRequest. Each docker image can be generally deployed on any miners. The pallet contains logic with off-chain softwares / models executions. 3-zkc related logics also will be implemented in this pallet. | -| | Functions | 1). `pub fn deploy(eid:u32, mid:u32, iNFT_id:u64)` The function is utilized to deploy one dAPI (ie., iNFT) on a specific miner and build off-chain connection to the dAPI user.
          2). `pub fn docker_manager()` It is only called at the first time when the miner connects to the blockchain to start a off-chain computation resource management related things such as 3-level dCache dispatch.
          3). `pub fn modify_miner_params(mid:u32, args:Vec)` It is an optional interface for miner to modify some on-chain parameters for adjustment computation. The implementation will be very careful to cause any security issues. 4). `fn distribute_rewards()` It can distribute Gas fee to miners| -| | Struct| `pub struct MinerParams`
          `pub struct EntityData`
          `pub struct EntityRuntime`| -| | Storage | `MinerParams get(fn get_miner_params): map hasher(blake2_128_concat) u32 => MinerParams;`
          `EntityData get(fn get_entity_data): map hasher(blake2_128_concat) u32 => Vec;`
          `EntityRuntime get(fn get_entity_runtime): map hasher(blake2_128_concat) u32 => Vec;`| -| 2. | pallet-DAO | A DAO of judgement court, dAPI user raise sue to determine the punishment of malfunction miners / services and return sue claimed tokens to dAPI user.| -| |Functions |`pub fn submit_sue(eid:u32)` dAPI User submit sue claims for malfunction.
          `pub fn vote_sue(eid:u32, sid:u32)` Jury evaluates and votes the sue submission to determine punishment.
          `pub fn process_sue(sid:u32)` Process the accepted sue claims of dAPI user to slash malfunction miner / dAPI. The tokens will be paid to dAPI user and treasury with a ratio. | -| | Struct| `pub struct Sue` -| | Storage| `SueList get(fn get_sue_list): map hasher(blake2_128_concat) u32 => Vec;` -| 4. | UI & Frontend | This part is implemented by [substrate front-end template](https://github.com/substrate-developer-hub/substrate-front-end-template). The frontend web interface contains DAO procedures related functions which including user sue judgement. A special document website is developed to guide entities to participant DAO events. | +| 0b. | Documentation | We will provide both inline documentation of the code and basic tutorials that explains and guides to SaaS3 DAO. | +| 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 for pallet-DAO | +| 0d. | Docker | We will provide a Dockerfile that can be used to test all the functionality delivered with this milestone. | +| 0e. | Article | We will publish an **article** that explains the usage of SaaS3 DAO. | +| 1. | pallet-court | A pallet of court DAO, dAPI user raise sue to determine the punishment of malfunction miners / services and return sue claimed tokens to dAPI user. | +| | Functions | `pub fn submit_sue(origin, value, eid)` dAPI User submit sue claims for malfunction.
          `pub fn vote_sue(origin, value, eid, sid)` Jury evaluates and votes the sue submission to determine punishment.
          `pub fn process_sue(origin, sid)` Process the accepted sue claims of dAPI user to slash malfunction miner / dAPI. The tokens will be paid to dAPI user and treasury with a ratio. | +| | Struct| `pub struct Sue{sid, eid, claims, statement}` | +| | Storage| `pub type SueList = StorageValue<_, BoundedVec, ValueQuery>;` List of all sue claims. | +| | Events | `SueSubmitted { user, value, eid }`
          `SueVoted { user, value, eid, sid }`
          `SueCompleted { sid }` | +| 2. | pallet-treasury | A pallet of SaaS3 DAO treasury. It sends or receives token based on different situations. It is built on top of [FRAME Treasury Pallet](https://github.com/paritytech/substrate/tree/master/frame/treasury), with some additional functionalities. | +| | Functions | `pub fn receive(origin, value, category)` Receive tokens with categorized reason, such as commission fees and miner node malfunctions.
          `pub fn claim_rewards(origin, value)` Court Jury members claim their rewards for their contribution in Court DAO. | +| | Storage | `pub type JuryRewards = StorageMap<_, Twox64Concat, AccountId, Rewards, OptionQuery>;` Mapping from account id to rewards which can be claimed. | +| | Events | `Received {from, value, category }`
          `Claimed { user, value }` | +| 3. | UI & Frontend | This part is implemented by [substrate front-end template](https://github.com/substrate-developer-hub/substrate-front-end-template). The frontend web interface contains DAO procedures related functions which including user sue judgement. A special document website is developed to guide entities to participate in DAO events. | ## Future Plans -- Initially, the parathreads will be utilized to connect the relay chain. Once the project goes well, we will participate slot auction. +- Initially, Phala will be exploited as the oracle miner provider, but SaaS3 will build the own TEE chain in the future. - Continue developing and polishing the project to flourish SaaS3 ecosystem to burst the web3 world based on Polkadot / Kusama / Substrate multi-chain system. -- Provide more reliable efficient computation service which can run Polkadot / Kusama validator dockers. ## Additional Information :heavy_plus_sign: **How did you hear about the Grants Program?** -web3 Foundation Website +Web3 Foundation Website **Related Files** -- PitchDeck: https://www.saas3.io/file/PitchDeck_SaaS3.pdf - SaaS3 website: https://saas3.io -- iNFT Demo (move to RMRK standard soon): https://saas3.io/non-api-nft -- Whitepaper(Beta Version): https://www.saas3.io/file/SaaS3Whitepaper.pdf +- Whitepaper: https://www.saas3.io/file/SaaS3Whitepaper.pdf **Other Grants** diff --git a/applications/ScoutCoinFabrik.md b/applications/ScoutCoinFabrik.md new file mode 100644 index 00000000000..f4c1c286733 --- /dev/null +++ b/applications/ScoutCoinFabrik.md @@ -0,0 +1,107 @@ +# Scout CoinFabrik +- **Team Name:** CoinFabrik (Nektra S.A) +- **Payment Address:** 0xf488039EDe6B38D7689fDCC6A9FC2dd0EF39D54e (USDT) +- **[Level]:** 2 + +## Project Overview :page_facing_up: + +### Overview + +Scout: Security Analysis Tool + +We are building an extensible open-source tool (or set of tools) to assist Rust Polkadot / Kusama smart contract developers to detect common security issues and deviations from best practices. To improve coverage and precision, we will persist in research efforts on static and dynamic analysis techniques. + +This tool will help developers write secure and more robust smart contracts. + +Our interest in this project comes from our experience in manual auditing and our usage of comparable tools in other blockchains. + + +### Project Details + +We have already conducted research work with the Universidad de Buenos Aires to better comprehend the current status of analysis tools built for Rust, while foreseeing different lines of development. + +We are currently working on tools to assist developers to apply best practices and to identify possible vulnerabilities. + +### Ecosystem Fit + +We believe we can bring value to the Polkadot / Kusama community by offering a tool to detect security bugs from a development perspective. By including this tool in their toolchain, Polkadot / Kusama developers will be assisted to remove bugs in their code, raising the quality and security of their smart contracts. + +## Team :busts_in_silhouette: + +### Team members + +- Ariel Wassbein, Head of Reaseach +- Valeria Caracciolo, Business Develpoment +- CoinFabrik's development and auditing team - when required. + +### 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 180 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, 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. + +### Team Code Repos + +- https://gitlab.com/coinfabrik-private/data/frecuencia-de-vulnerabilidades +- https://drive.google.com/drive/u/1/folders/1HoaL6EXX1Wky7e1SHYBY6oIZDGK2sgDD + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/arielwaissbein/ +- https://www.linkedin.com/in/valeriacaracciolo/ + + +## Development Status :open_book: + +We have been working on different aspects of the tool: +- Research on security analysis tools for Rust-based blockchains. +- Listing common vulnerabilities and usability issues in different systems and technologies. +- Tools to assist developers. + +We briefly validated the idea of the development described in this application with David Hawig and Bhargav Bhatt from Web3 Foundation, who encourage us to apply for this grant. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 1 month +- **Full-Time Equivalent (FTE):** 5 FTE +- **Total Costs:** 15,000 U$D + +### Milestone 1: Proof of Concept + +- **Estimated duration:** 1 month (Day 1 to Day 30) +- **FTE:** 5 +- **Costs:** 15,000 U$D + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT +| 0b. | Documentation | We will provide a report, listing relevant security issues introduced in smart contracts developed with ink!. This will include a summary of findings and how the results were procured, a detailed description of each vulnerability/best practice, and links to the code that exemplifies them. +| 0c. | Testing and Testing Guide | No tests with be produced at this stage. +| 0d. | Docker | Does not apply at this stage. +| 0e. | Article | We will upload to our blog a report summary. + **1** | Research | Producing a curated list of vulnerabilities, best practices, and enhancements related to smart contracts written in ink!, considering the list of [analysis categories](https://blog.coinfabrik.com/analysis-categories/) currently used for our manual smart contract audits. + **2** | Development | Producing code examples and snippets of smart contracts written in ink! for each type of vulnerability from the list mentioned in 1. Research. + **3** | Development | Proof of concept code detecting some (relevant) issues included in the list of vulnerabilities and best practices. + + +## Future Plans + +(Our original plan was to apply for a 3 months grant, to reach a public release of the tool. But we were advised to apply for a shorter objective, so we are presenting only Milestone #1 from our plan) After completing this first milestone, we are planning on applying for 2 additional iterations to reach a tool prototype (Milestones #2) and public release (Milestones #3). Our mission is to continue to work on improving automated and assisted tools for finding security vulnerabilities and writing more secure code. Our objective is to help the Polkadot / Kusama community produce better and more secure code with these tools. + +## 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. Our inquiries were addressed by David Hawig and Bhargav Bhatt, who also gently advised us on this presentation. diff --git a/applications/ScoutCoinFabrik_2.md b/applications/ScoutCoinFabrik_2.md new file mode 100644 index 00000000000..f627032e0a1 --- /dev/null +++ b/applications/ScoutCoinFabrik_2.md @@ -0,0 +1,116 @@ +# Scout CoinFabrik +- **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 + +Scout: Security Analysis Tool + +We are building an extensible open-source tool (or set of tools) to assist ink! smart contract developers detect common security issues and deviations from best practices. To improve coverage and precision, we will persist in research efforts on static and dynamic analysis techniques. + +This tool will help developers write secure and more robust smart contracts. + +Our interest in this project comes from our experience in manual auditing and our usage of comparable tools in other blockchains. + + +### Project Details + +We have already conducted research work with the University of Buenos Aires to better comprehend the current status of analysis tools built for Rust, while foreseeing different lines of development. + +We are currently working on tools to assist developers to apply best practices and to identify possible vulnerabilities. + +### Ecosystem Fit + +We believe we can bring value to the Polkadot / Kusama community by offering a tool to detect security bugs from a development perspective. By including this tool in their toolchain, ink! developers will be assisted to remove bugs in their code, raising the quality and security of their smart contracts. + +## Team :busts_in_silhouette: + +### Team members + +- Ariel Wassbein, Head of Reaseach +- Valeria Caracciolo, Business Develpoment +- CoinFabrik's development and auditing team - when required. + +### 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 180 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. + +### Team Code Repos + +- https://github.com/CoinFabrik/web3-grant +- https://gitlab.com/coinfabrik-private/data/frecuencia-de-vulnerabilidades +- https://drive.google.com/drive/u/1/folders/1HoaL6EXX1Wky7e1SHYBY6oIZDGK2sgDD + +### Team LinkedIn Profiles (if available) + +- https://www.linkedin.com/in/arielwaissbein/ +- https://www.linkedin.com/in/valeriacaracciolo/ + + +## Development Status :open_book: + +We have been working on different aspects of the tool: +- Research on security analysis tools for Rust-based blockchains, applicable to ink! Smart contracts +- Listing common vulnerabilities, best practices, and enhancements related to smart contracts written in ink! +- Producing code examples and snippets of smart contracts showing the mentioned issues. +- Built a PoC (proof of concept) of a tool that identifies relevant security issues. + +We briefly validated the idea of the development described in this application with David Hawig and Bhargav Bhatt from Web3 Foundation, who encourage us to apply for this grant. + +We have finished the first milestone of this project ([Milestone 1 of ScoutCoinFabrik PoC](https://github.com/w3f/Grants-Program/blob/master/applications/ScoutCoinFabrik.md#milestone-1-proof-of-concept)), accomplishing all the deliverables listed in the milestone table. + +Please note, however, that this milestone is the second grant associated with the same project: [ScoutCoinFabrik](https://github.com/CoinFabrik/web3-grant). The first grant focused on the tool’s PoC, and in this second grant we aim to develop a prototype. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 5 weeks +- **Full-Time Equivalent (FTE):** 5 FTE +- **Total Costs:** 30,000 USD + +### Milestone 1: Prototype + +- **Estimated duration:** 5 weeks +- **FTE:** 5 +- **Costs:** 30,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| 0a. | License | MIT | +| 0b. | Documentation | Documentation hosted on a separate webpage. | +| 0c. | Testing | Integration testing. Specific tests for every linting detector based on code examples and snippets of smart contracts. | +| 0d. | Docker | Does not apply at this stage. | +| 0e. | Article | We will upload a report summary to our blog. | + **1.a** | Research and Development | Vulnerability examples. In addition to the [examples developed in Milestone 1 of ScoutCoinFabrik PoC](https://github.com/w3f/Grants-Program/blob/master/applications/ScoutCoinFabrik.md#milestone-1-proof-of-concept), we will develop more code examples and snippets of vulnerabilities, best practices, and enhancements related to smart contracts written in ink!. | + **1.b** | Research and Development | Further example versions of [vulnerabilities developed in Milestone 1 of ScoutCoinFabrik PoC](https://github.com/CoinFabrik/web3-grant/tree/main/vulnerabilities). This step is geared to provide a wider set of examples, therefore improving our ability to measure the precision of our prototype and any other ink! vulnerability detection tool. | + **2.a** | Development | Building a prototype that improves over the [development of Milestone 1 of ScoutCoinFabrik PoC](https://github.com/w3f/Grants-Program/blob/master/applications/ScoutCoinFabrik.md#milestone-1-proof-of-concept), detecting more classes of vulnerabilities and improving in precision on existing detectors. We are to build a prototype that can analyze Rust code to detect vulnerabilities in ink! smart contracts and possibly in pallets and other pieces of code. This builds over [this proof-of-concept tool](https://github.com/CoinFabrik/web3-grant) we've built and [delivered as part of a grant for the web3 foundation](https://github.com/w3f/Grant-Milestone-Delivery/blob/master/deliveries/ScoutCoinFabrik-1.md) by:
          a) Moving from a proof-of-concept (PoC) tool to a robust tool that integrates with a popular IDE (VSCode), includes a CLI, etc,
          b) We will improve on the precision of the detectors we included in the PoC reducing the rate of false positives, and
          c) We will add more detectors in order to have a reasonable coverage of the relevant security vulnerabilities that happen in smart contracts. | + **2.b** | Development | Command line interface for the prototype. For this prototype, we want to develop a simple command line interface like the one used in other static analyzers from other blockchains (eg: [Slither](https://github.com/crytic/slither), [Rustle](https://github.com/blocksecteam/rustle)).
          In particular, we will develop the possibility to run the prototype on smart contract files or directories.
          The base command will be: `cargo scout file_name.rs`
          We will also include options for running subsets of detectors and triggering errors for CI/CD workflows. | + **2.c** | Development | VSCode integration for the prototype. Our VSCode development will list security issues, highlight issues with squiggles and hover-over descriptions. We will seek compatibility of this development with other relevant ink! extensions such as [Ink! Analyzer](https://w3f.github.io/Grants-Program/applications/ink-analyzer#future-plans). | + **3** | Evaluation | Prototype validation against a selection of projects deployed on testnet or mainnet in order to evaluate detector precision. Evaluation report and detector improvement. | + + +## Future Plans + +(Our original plan was to apply for a 3 milestones grant, to reach a public release of the tool. But we were advised to apply for a shorter objective) After completing the PoC in our first milestone (Milestone #1), we are now applying for this second milestone to reach a tool prototype (Milestone #2). We envison a third milestone together with a public release (Milestone #3). Our mission is to continue to work on improving automated and assisted tools for finding security vulnerabilities and writing more secure code. Our objective is to help the Polkadot / Kusama community produce better and more secure code with these tools. + +## 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. Our inquiries were addressed by David Hawig and Bhargav Bhatt, who also gently advised us on this presentation. diff --git a/applications/Security_Marketplace.md b/applications/Security_Marketplace.md new file mode 100644 index 00000000000..b512238cc51 --- /dev/null +++ b/applications/Security_Marketplace.md @@ -0,0 +1,294 @@ +# Security Marketplace + +- **Team Name:** Antier Solutions +- **Payment Address:** Fiat +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + +## Project Overview :page_facing_up: +The proposal is in response to the RFP : [Decentralised Security marketplace](https://github.com/w3f/Grants-Program/blob/master/docs/RFPs/decentralized-security-marketplace.md). + +### Overview + +The envisioned project aims to develop a decentralized security marketplace platform much to the liking of similar existing platforms like [hackenproof](https://hackenproof.com/) and [Immunefi](https://immunefi.com/), with its unique value propositions being the aim to reward users for submitting full-blown security/Functional audits instead of individual vulnerabilities. + +Our envisioned platform will be a hybrid model that combines smart contract functionality with a centralized server to optimize gas fees. We understand that paying gas fees for small transactions can cause hesitation among users and thus have come up with a solution that optimizes the platform's operation by shifting its peripheral features off-chain while retaining its decentralized nature through the use of smart contracts for implementation of its core functionality such as escrow and governance. + +The proposed platform will be designed to provide an incentivized system that rewards auditors for submitting comprehensive audit reports on schedule while also punishing those who fail to do so. + +Our platform is also envisioned to feature a reputation system that allows auditors to build and maintain their reputations based on their past auditing records. The reputation system will act as a measure of trustworthiness for auditors while facilitating the project creators in the selection process of the right auditors for their projects. Moreover, users who have earned enough reputation will be entitled to the Arbiter role, which allows them to vote in support of or against a submitted audit based on whether it meets all of the scope requirements as outlined in the project description for a share of validation fees. + +### Project Details + +**Technical Diagram** + +![Technical Architecture](https://github-production-user-asset-6210df.s3.amazonaws.com/106224868/241970938-b0e0fda7-83bb-4001-97e2-66546db2eeb5.png) + + +**Pre Script:** + +1) The below lifecycle is not a blueprint or final version of the + project, but instead, a basic outline to depict the thinking + process involved in the proposal. + +2) The mathematical figures are by no means final + and will be concluded once the production is underway after + carefully considering the market situation. + +Here is an envisioned lifecycle of a project on our platform. + +1. Users will begin their journey on our platform by registering on our sign-up page. +2. Users can then proceed to our login page and then the dashboard after completing the validation process there. +3. Users can be broadly classified as : + Patrons: Users, generally the owners of big platforms that wish to avail of the auditing services. + Auditors: Users that are willing to offer their auditing services on the platform. + Arbiters: Trusted community members that will review the auditor’s work and verify the auditor’s claim for rewards. +4. The dashboard can be used to access all the available Projects offered by patrons on the platform, the user from there can create a post (Audit Request) + for their project, bid for already existing projects, or switch to the arbiter's dashboard if authorized. +5. The patron can create a post which will entail: + A) Project Status: Whether the project is active, pending, retrieved, completed, awaiting validation, or expired. Will be active by default on creation. + B) Type of Audit: Whether it includes Smart Contract Audit or penetration testing or Performance testing. Patrons can choose multiple tags. This will help + auditors in sorting through the projects to find the project they wish to assess for auditing. + C) Project description: A description of the working of a project by owners/developers to aid auditors, can consist of document links. + D) Github link to the Project. + E) Offered Amount: The maximum amount offered for a successful audit, value in terms of stablecoins/USD pegged tokens. + F) Audit Expectations: Any expectations the project developers/owners might have from the auditors such as including suggestions, checking test coverage/quality, + expected deadline, and scope of the audit. Arbiters will evaluate the auditor’s work on its basis. +6. The Patron will have to add the promised amount to the escrow contract at the very time of posting. +7. To elaborate on project status, The initial status of any project that will be posted will be active by default and hence, will be open to offers from auditors on the platform. + Retrieved would mean that the project was retrieved by the project’s patrons, the status of a project can only be turned to retrieved if it's in active status, and the option of retrieving will be made unavailable in any other status. + Pending would mean that an auditor has been commissioned and that the audit is underway. + Awaiting Validation would mean, the submitted auditing report is currently being scrutinized by Arbiters to ascertain it meets the pre-defined scope. + If for some reason an offer is not met even after two weeks of the expected deadline, the project will be marked expired. + + ![Project Lifecycle](https://github-production-user-asset-6210df.s3.amazonaws.com/106224868/241969866-5024f3da-94a2-4efc-a436-963c70249fc6.png) + +8. An auditor can bid on projects they want to audit. A bid includes a proposed deadline they can complete the project in and an amount they wish to get in exchange for the project. + Auditors, just like any user can view all the posts and decide which one they wish to make a bid on. They can filter through the list of projects for a particular range of amounts, or for a specific Audit type. +9. At a time, a new Auditor can only work on 1 active project. This means that a new user can make multiple bids (Limited to 5 at a time) but once one of them is accepted, his other bids will be retrieved and he cannot bid on other projects until he finishes the active audit. +10. As the auditor matures on the platform, Their active audit limit will be increased by 1 for every 3rd successful audit they deliver although this will be capped at 7. So an auditor can + never have more than 7 simultaneously active audits ongoing at a time. +11. The Bids made by auditors will be publicly visible and patrons can decide on whom they wish to delegate the job to based on their offers and their profiles. +12. The user profiles will be stored off-chain in a central database allowing users to edit them as they please and keep their feats and experiences updated. This will include a unique username, a bio where they can mention their previous experiences with auditing, links to their socials, and sample audit reports. An optional KYC can be done to verify identity. + This feature will be particularly important for auditors to eliminate identity theft and impersonation threats to reputable security companies and/or well-known individual auditors. Hence helping project creators while deciding on which offer to accept. +13. Once the project’s patron accepts one of the listed bids, the project is marked pending, and the selected auditor is notified on their profile and their email address about the start of the auditing process. + Patron can not withdraw the amount at this stage. The auditor will be given a buffer of 12 hours to accept the job assuming that he has taken that much time to check the mail or website notification. +14. The auditor commissioned with the project will then have till the proposed deadline to submit a successful audit. They can upload the audit in pdf format to the platform. There will be a penalty + for late submission of the audit which will be a certain amount of the decided amount for submission later than the deadline to 1 week and an increased penalty for the second week. After two weeks + the project’s status will automatically be turned to expired, The commissioned auditor will be given a negative point, and the project’s patron will be refunded the whole amount. +15. The submitted Audit report will then be sent to the patron which he can accept, in which case after subtraction of the platform fee, the promised amount will be sent to the auditor. +16. In case, the patron isn’t satisfied with the audit report, the dispute will then be handled by randomly selected active arbiters who will vote for or against the audit report by judging it against + the expectations of the patron specified at the start of the audit. +17. In case, the submitted project is downvoted by 5 arbiters for the first time, a deadline extension of 1 day will be granted to the auditor at no penalty (for any altercations that can be quickly + made to the report), a 6-day extension will be granted the second time around at certain percentage of penalty (for major scope misses). If the audit report is downvoted for the third time, the + project status will be marked as expired, and the project creators can retrieve the whole staked amount. The auditor commissioned will be given a negative review on-chain. +18. If 5 of the arbiters are satisfied with the audit report, then the patron will have no option but to accept the report and the promised amount will be transacted to the auditor after subtracting + the platform fee and +19. The auditors will get platform Points along their profile based on their actions, for every: + 1 successful audit completion: 1XP point (Increases with more and more audits) + 1 unsuccessful audit: -3XP points (Adds up) +21. The point system is designed to help patrons identify reputable members of the community as well as alert them of newcomers and bad elements. Once a user hits a -6XP rating, he cannot bid anymore + on the platform. +22. The proposed platform will charge a certain amount as a platform fee and the arbiter’s commission, the remaining funds will be transferred to the auditor’s wallet address connected to their profile. + + + +The peripheral components in the above-suggested platform such as user +profiles, projects posted(not yet completed), and KYC procedure will be +carried out with the help of Back-end Services, and the data will be +stored in a centralised database to facilitate users to change and +update their profiles at will whereas, The core functionalities such as +escrow, auditing achievements, and records will be stored in a +decentralised manner using smart contracts developed with !ink. + +The Data in the model will be stored either in the centralised database +or on the blockchain and hence no data will be lost even if the server is +shut for some unforseen reason. + +**Proposed TechStack** +- BackEnd : NodeJs +- FrontEnd : ReactJS using Astar.js +- Smart Contracts : !ink + +**WireFrames** + +![Login Page]( https://github.com/viswatejay/RFP/assets/106224868/38a52e06-cdf9-4090-8c67-afe8796638ba ) + +--- + +![SignUp Page]( https://github.com/viswatejay/RFP/assets/106224868/820530e5-0976-49b2-8351-efb86314a21c ) + +--- + +![OTP Verification Page]( https://github.com/viswatejay/RFP/assets/106224868/ee1ddb45-cc59-4979-b4a1-e3785174b3e2 ) + +--- + +![ Dashboard Page ]( https://github.com/viswatejay/RFP/assets/106224868/40cf5cb4-5d6e-4573-9223-851f82ab40a5 ) + +--- + +![ Detail Page ]( https://github.com/viswatejay/RFP/assets/106224868/8845baea-fc9c-480a-93d7-7692c9c59020 ) + +--- + +![ Profile Page ]( https://github.com/viswatejay/RFP/assets/106224868/92b8b522-41b4-4ac9-9485-39f493056eea ) + +--- + +![ Profile-MyAudits Page]( https://github.com/viswatejay/RFP/assets/106224868/48c2b803-a68b-4613-9344-850d668f0ca4 ) + +--- + +![ Profile-PendingAudits Page]( https://github.com/viswatejay/RFP/assets/106224868/853c43b2-f3e9-4c30-91b8-6da00650c6ba ) + +--- + +![ Create Post Page ]( https://github.com/viswatejay/RFP/assets/106224868/44caf541-f311-41e3-b415-e009bcdbe37c ) + +### Ecosystem Fit + + - The escrow smart contract will be developed in a platform-agnostic manner which will make it beneficial for future use cases. + - The negative badge mapping can be used by other platforms in the ecosystem to create a bot blacklist. + - The platform helps project owners in the ecosystem to find auditors/whitehats and vice versa. + +## Team :busts_in_silhouette: + +### Team members + +- Ankit Bhatia +- Parth Chaudhary +- Niketan Saini +- Nitin Sharma +- Vishant Mittal +- Shubham Aswal +- Abhishek Dhiman + +### Contact + +- **Contact Name:** Ankit Bhatia +- **Contact Email:** ankit.bhatia@antiersolutions.com +- **Website:** https://www.antiersolutions.com/ + +### Legal Structure + +- **Registered Address:** E-221, Phase 8B, Industrial Area, Sector 74, Sahibzada Ajit Singh Nagar, Punjab 160059 +- **Registered Legal Entity:** Antier Solutions Pvt. Ltd. + +### Team's experience + +Antier solutions entered the blockchain domain in 2016, Back when one bitcoin was not even a 1000$. The path from back there +to where we stand currently has blessed our organization not only with rewards but also with an abundance of experience. +Our Smart contract Auditing team is led by some of the most experienced and competitive developers of the organization as well as the ecosystem. +The team is well-experienced in both the development side as well as the debugging side of an SDLC and has an eye for the bugs as well as respect +for standards which, we believe, makes us a perfect fit to be the practitioner of this RFP. + +Here are some of the feats, achievements our organisation boasts of: + +1) Developed validator and nominator apps for substrate-based blockchains. +2) Customised default reward mechanism in the staking pal of the substrate chain by integrating the sustainability and + reliability score of the validators in the current reward system. +4) Integrated EVM and WASM-based virtual machines natively in the substrate chain so the chain could support both EVM(Metamask, + Remix, Web3.js, etc) and WASM(WebAssembly target, INK framework, etc) tooling. +5) Replicated whole polkadot ecosystem(Relay chain, Parachains, XCM), Where parachains are use case specific chains and communicate + through XCM protocol with each other. +6) Developed several NFT Marketplace contracts both decentralized and hybrid across various blockchains such as [Hungama](https://heftyverse.xyz/), + [SkodaVerse](https://www.skoda-auto.com/world/skodaverse), [Fanverse](https://www.fan-verse.io/) just to name a few. +7) Developed many DeFi projects across multiple blockchains such as [Shido, Staking](https://dex.shido.io/staking-page), [Shido, Perpetuals](https://perp.shido.io/), [YSL](https://ysl.io/), [Lithium](https://lithium.ventures/) and many more. +8) We have also developed an Asset Tokenization solution based on ERC3643 on EVM, Aptos & Provenance chain for some of the renowned Financial Institutions. The + asset classes tokenized are Real Estate, Securities, Private Equity, and commodities such as Gold. Can't share the platform details, as we are under strict NDA. +9) We are also developing some in-house Web3 solutions such as Relayer Hub for meta-transactions, Decentralized Token Bridge, a multi-sig solution like Gnosis-safe + and we are actively researching and developing in areas such as multi-party Computation (MPC), Account Abstraction (AA, ERC4337), zk proofs and many more. + + +- Our team has also been proactively participating in the Substrate Stack exchange and we ask/answer question related to ink!, Substrate, parachain. We rank in the top 6% people in the Substrate Stack Exchange. + +- Profiles of our team: +1. https://substrate.stackexchange.com/users/2372/arunjot-singh +2. https://substrate.stackexchange.com/users/2281/amit-kumar-yadav +3. https://substrate.stackexchange.com/users/354/shubham-gupta + + +### Some Live Sites: + +- https://ysl.io/nft +- https://heftyverse.xyz/ +- https://www.fan-verse.io/ +- https://dex.shido.io/staking-page +- https://perp.shido.io/ +- https://www.skoda-auto.com/world/skodaverse +- https://collective-vault.planetinverse.com/ + + +### Team LinkedIn Profiles + +- https://www.linkedin.com/in/ankit-bhatia-b6833370/ +- https://www.linkedin.com/in/niketan-saini-5a26a0177/ +- https://www.linkedin.com/in/shubham-aswal-528462130/ +- https://www.linkedin.com/in/nitin-sharma-9b00b6188/ +- https://www.linkedin.com/in/parth-chaudhary-b5220a257/ +- https://www.linkedin.com/in/abhishek-dhiman-6368a2187/ +- https://www.linkedin.com/in/mittalv/ + + +## Development Status :open_book: + +Awaiting Response. + +## Development Roadmap :nut_and_bolt: + +### Overview + +- **Total Estimated Duration:** 12-14 weeks +- **Full-Time Equivalent (FTE):** 4,5 +- **Total Costs:** 29,920 USD + +### Milestone 1 — UI/UX designs, Smart Contracts & Backend Services + +- **Estimated duration:** 7-8 weeks +- **FTE:** 5 +- **Costs:** 19,320 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.| +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| 1 | UI/UX | We will deliver complete UI/UX designs. | +| 2 | Reputation Token Contract| This will be a non-transferrable token smart contract(Soul Bound Token) that will serve as auditors' reward and as proof of reputation points after the successful completion of an Audit. | +| 3 | Escrow Contract| This will be a master contract where all tokens will be managed by patrons and distributed to the Auditors after the successful closure of the Audit.This contract will also store all hashes of the audit reports. Which can be retrieved even when the platform goes down. | +| 4 | Arbiter's voting Contract| This contract will have specific arbiters for every audit thread where they can participate in the voting. | +| 5 | Node Services | We will deliver the backend services for login , sign up, 2FA and Profile creation | + + + +### Milestone 2 — Application & Deliveries + +- **Estimated Duration:** 5-6 weeks +- **FTE:** 4 +- **Costs:** 10,600 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 / GPLv3 / MIT / Unlicense | +| **0b.** | Documentation | We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works.| +| **0c.** | Testing and Testing Guide | Core functions will be fully covered by comprehensive unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | +| **0d.** | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | +| **0e** | Article | We will publish an **article**/workshop that explains [...] (what was done/achieved as part of the grant). (Content, language and medium should reflect your target audience described above.) | +| 1 | Node Services | We will deliver the remaining back end services including Post creation and Bidding system. | +| 2 | Front End | We will deliver the completely functional DApp integrated with the Smart contracts and backend services. The working application will have all the 9 pages as per the wireframes and above mentioned. The application will be deployed on the provided servers. | + + + +## Future Plans + +- As mentioned earlier, Our organization plans to serve as the Arbiters in the early stages of + the platform's deployment untill reliable auditors emerge on the platform who have been actively + contributing to the community to make this process decentralised in true sense. + +## Referral Program (optional) :moneybag: + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** +Through RFP Portal. diff --git a/applications/Shivarthu.md b/applications/Shivarthu.md index 73a7c2724da..d6a83b9ed76 100644 --- a/applications/Shivarthu.md +++ b/applications/Shivarthu.md @@ -1,14 +1,12 @@ -# W3F Open Grant Proposal +# Shivarthu > This document will be part of the terms and conditions of your agreement and therefore needs to contain all the required information about the project. Don't remove any of the mandatory parts presented in bold letters or as headlines! Lines starting with a `>` (such as this one) can be removed. > > See the [Open Grants Program Process](https://github.com/w3f/Open-Grants-Program/#pencil-process) on how to submit a proposal. -* **Project Name:** Shivarthu * **Team Name:** Reaudito * **Payment Address:** 0x7e30FB962f951ef78D901865F87DD036fc5aa946 (DAI) - > ⚠️ *The combination of your GitHub account submitting the application and the payment address above will be your unique identifier during the program. Please keep them safe.* ## Project Overview :page_facing_up: @@ -22,58 +20,60 @@ If this is an application for a follow-up grant (the continuation of an earlier, Shivarthu: The blockchain-based decentralized governance system. Democracy is about fair and equal treatment of everyone in a country. But it becomes unrealistic to achieve when political parties have their conflict of interest, and leaders don’t have the expertise to make evidence-based policies and neither have the skill and manpower for solving problems that surround our society and ecosystem. The new fair democracy provides an elegant way of governance that separates the representative responsibility according to their specialization and can grow into any complexity. The governance is divided into various departments, and each department is supervised by representatives with expertise in the field. Voters are rational and need to have enough knowledge about the departments and the department problems, in order to vote for the selecting representatives of a department. The selection process of representatives is “difficult in and easy out”, which allows only utilitarian actors to hold the responsibility, weeding out frivolous ones. -https://shivarthu.reaudito.com/paper/Shivarthu_whitepaper.pdf +https://shivarthu.reaudito.com/paper/Shivarthu_whitepaper.pdf Shivarthu will be build on Substrate. Our democracy has many challenges, blockchain can provide a way to tackle those challenges by minimizing trust through game theory. That made our team interested in creating this project. - ### Project Details Project Github link: https://github.com/amiyatulu/shivarthu +#### Departments -#### Departments: The governance is divided into many departments like education, infrastructure, health, community service for every locality. -#### Expertise evaluation of representatives : -Voters and especially representatives need to have some experience or expertise in the department. Experience is required because education about the department leads to better decision making. -Their experience is evaluated by schelling game. + +#### Expertise evaluation of representatives + +Voters and especially representatives need to have some experience or expertise in the department. Experience is required because education about the department leads to better decision making. +Their experience is evaluated by schelling game. portfolio -#### Schelling Game: +#### Schelling Game + In this project, the Schelling game is used for experise evaluation and review of projects. We use a modification of Schelling game named score Schelling game for fund distribution of projects. -Juror applies for making a decision like whether the required experience can be accepted or review quality of projects is acceptable. The probability of being drawn as a juror is proportional to the amount of tokens a juror stakes. The higher the amount of tokens he stakes, the higher the probability that he will be drawn as a juror. Also, jurors are drawn randomly. This protects the system from sybil attacks. +Juror applies for making a decision like whether the required experience can be accepted or review quality of projects is acceptable. The probability of being drawn as a juror is proportional to the amount of tokens a juror stakes. The higher the amount of tokens he stakes, the higher the probability that he will be drawn as a juror. Also, jurors are drawn randomly. This protects the system from sybil attacks. We will use the substrate randomness trait for generating a random number. https://substrate.dev/recipes/randomness.html -Then jurors will vote for their decision using the commit and reveal scheme. In the commit phase, they submit the hash of the vote string. Then, in the reveal phase, they submit the hash and the vote string. If the vote string matches with the hash, then the vote is accepted. -If a juror's vote is coherent (more than 51% of other jurors agree) then they receive incentives, otherwise, incentives are deducted from the stake of the juror. - -#### Voting for selection of representatives: -The election is multi-winner approval. We will use seq-phragmen of the substrate to select the representatives. Here, we will keep vote weight as reputation score (instead of stake), the amount of score they obtained through the participation of network. -https://substrate.dev/rustdocs/v3.0.0/sp_npos_elections/fn.seq_phragmen.html -Approval Voting: -Approval Voting -Winners: +Then jurors will vote for their decision using the commit and reveal scheme. In the commit phase, they submit the hash of the vote string. Then, in the reveal phase, they submit the hash and the vote string. If the vote string matches with the hash, then the vote is accepted. +If a juror's vote is coherent (more than 51% of other jurors agree) then they receive incentives, otherwise, incentives are deducted from the stake of the juror. + +#### Voting for selection of representatives + +The election is multi-winner approval. We will use seq-phragmen of the substrate to select the representatives. Here, we will keep vote weight as reputation score (instead of stake), the amount of score they obtained through the participation of network. +https://substrate.dev/rustdocs/v3.0.0/sp_npos_elections/fn.seq_phragmen.html +Approval Voting: +Approval Voting +Winners: Winner -#### Project application and acceptance: -The representatives are in charge of accepting the incoming projects for funding. +#### Project application and acceptance + +The representatives are in charge of accepting the incoming projects for funding. People will submit their problems, for example, waterlogging in the locality. Then experts all around the globe will submit the solution. The solution will be peer-reviewed to check its pros, cons, and suggest improvements that can be made. The review must meet the scientific guidelines. The solution can undergo revision through peer review feedback. -The solution provider and peer reviewer have to stake some money to receive incentives for their work. The solution and peer review will again be approved and disapproved through the shelling game after checking whether the content meets the quality as recommended in scientific guidelines. The solutions provider and reviewer will get the incentives if it gets approved, otherwise, some money will be cut from the stake. It creates pressure on the reviewer to maintain quality without noise. -Problem Solution +The solution provider and peer reviewer have to stake some money to receive incentives for their work. The solution and peer review will again be approved and disapproved through the shelling game after checking whether the content meets the quality as recommended in scientific guidelines. The solutions provider and reviewer will get the incentives if it gets approved, otherwise, some money will be cut from the stake. It creates pressure on the reviewer to maintain quality without noise. +Problem Solution The representatives of the department will select the most optimal solution. -After that persons wanting to take the lead to implement the solution will apply. Again representatives will select the best project leader from the application. +After that persons wanting to take the lead to implement the solution will apply. Again representatives will select the best project leader from the application. -Leadership - +Leadership +### Money for projects -### Money for projects: - -People can either directly donate to the projects or to the department funding pool. Transaction fees of governance token are also collected and kept in the tax funding pool. +People can either directly donate to the projects or to the department funding pool. Transaction fees of governance token are also collected and kept in the tax funding pool. The amount you can contribute to the department funding pool is calculated using the following formula. @@ -89,12 +89,14 @@ Your stake = 100 You can contribute to the funding pool = 50000/10000 * 100 -Then, funding to the projects is distributed through the score schelling game. +Then, funding to the projects is distributed through the score schelling game. + +### Price discovery through Score Schelling Game -### Price discovery through Score Schelling Game: You can rate the project from 1-5, without knowing what others are assigning. If the “mean” of all the product rating is near to your rating then the juror will get incentives, otherwise, juror incentives will be deducted. So, the juror will try to match the score with what others will assign based on information available rather than defecting by any arbitrary rating. We can discover the prices of projects that need to be funded from a common funding pool. Here is an algorithm: + 1) When you submit a project, you need to provide details of the funding needed for work to be done. You can’t provide a funding amount value of more than 4/5 power of the total funding pool amount. e.g. If the total funding pool has $50000, you can’t assign a value larger than $5743 @@ -105,22 +107,17 @@ https://gateway.ipfs.io/ipfs/QmdgL7ytRPSE8vyp5KBffaAjmhGRLusiPcEbt9VWFkgMjf Score Schelling Game - 3) Then, we will do quality score voting Schelling game that checks the project meets the quality guidelines. The score range is 0-5 4) The amount of funding will be directly proportional to (Predicted Price) * (Quality Score/5*2) Code: https://gateway.ipfs.io/ipfs/QmcPfQFJKzozLMHFkAesDQc9n2CaEh6M8M4VWdsozgWRB9 The algorithm tries to meet the values of teal organization through reduced compensation inequality - - - ### Ecosystem Fit +The project will be built on the substrate as a parachain or parathread. -The project will be built on the substrate as a parachain or parathread. - -Other projects similar to it is gitcoin, but its not in Substrate / Polkadot / Kusama ecosystem. Gitcoin uses quadratic funding, but we will use score schelling game for allocation of funds. Gitcoin is for mainly blockchain projects, but our projects includes local community problems. +Other projects similar to it is gitcoin, but its not in Substrate / Polkadot / Kusama ecosystem. Gitcoin uses quadratic funding, but we will use score schelling game for allocation of funds. Gitcoin is for mainly blockchain projects, but our projects includes local community problems. ## Team :busts_in_silhouette: @@ -143,26 +140,17 @@ Other projects similar to it is gitcoin, but its not in Substrate / Polkadot / K ### Team's experience -Amiya Behera is a full-stack developer and has build many webapps and a few dapps. Has experience in substrate, rust, reactjs, python and also in building mobile apps in react native. +Amiya Behera is a full-stack developer and has build many webapps and a few dapps. Has experience in substrate, rust, reactjs, python and also in building mobile apps in react native. Soumya Ranjan Behera is also a full stack developer with experience in reactjs, react native and python. - - ### Team Code Repos * https://github.com/amiyatulu * https://github.com/soumyababu * https://github.com/amiyatulu/shivarthu - - - - - - ## Development Roadmap :nut_and_bolt: - ### Overview * **Total Estimated Duration:** 8 Months @@ -187,9 +175,6 @@ Soumya Ranjan Behera is also a full stack developer with experience in reactjs, |3.| Reactjs UI for Experience Evaluation| Uploading evidence of experience for the department using IPFS, UI for commit and reveal voting for schelling game and interaction of UI with substrate | |4.| Reactjs Approval Voting UI| Userfriendly UI for voting the representatives where their profile is shown | - - - ### Milestone 2 — Additional features * **Estimated Duration:** 4 month @@ -203,26 +188,22 @@ Soumya Ranjan Behera is also a full stack developer with experience in reactjs, | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | | 0e. | Article | We will publish an **article**/workshop that explains our project (what was done/achieved as part of the grant.) | -| 1. | Substrate module: Peer review system | Reviewing the projects using schelling game | -| 2. | Substrate module: Fund allocation | Allocating the fund using score schelling game | +| 1. | Substrate module: Peer review system | Reviewing the projects using schelling game | +| 2. | Substrate module: Fund allocation | Allocating the fund using score schelling game | | 3.| Reactjs UI for peer review system and Fund allocation | User friendly UI for reviewing the projects, schelling game voting interface, and fund allocation | | 4. | Search Engine| Offchain search engine for project discovery and finding representatives | - - - ## Future Plans Short-term: Improve the ideas with discussing with community Increase social media reach Write the source code - + Long-term: Onboard people into the app, and improve it taking feedback from the community. Enhance the app, provide upgrades when required. - ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** Web3 Foundation Website +**How did you hear about the Grants Program?** Web3 Foundation Website diff --git a/applications/Slushie Mixer.md b/applications/Slushie Mixer.md deleted file mode 100644 index be904ec12f4..00000000000 --- a/applications/Slushie Mixer.md +++ /dev/null @@ -1,211 +0,0 @@ -# W3F Open Grant Proposal - -* **Project Name:** [Slushie](https://github.com/4IRE-Labs/Slushie) -* **Team Name:** [4ire](https://github.com/4IRE-Labs) -* **Payment Address:** ERC 20 ADDRESS: 0xbb028626a2f51fd0f7be0ff5587686104dd0f6fe - - -## Project Overview :page_facing_up: - -[Mixer RFP](https://github.com/w3f/Grants-Program/blob/master/rfps/open/mixer.md) implementation. - -### Overview - -Polkadot uses an account-based Tx model, which easily enables linking activity between accounts. -To preserve on-chain anonymity, the options available to the user at the moment are limited to using centralised exchanges. -It requires transferring their funds to an exchange-controlled account and withdrawing them at a later point in time, to a different account. -While it works to an extent, there are major drawbacks: -* Users need to trust the exchange in the first place -* There is a fee associated with each transaction, usually both withdrawal and deposit, and sometimes also with creating an account -* The entire process is cumbersome -* If the user wants to *mix* the whole amount, analysis tools can still correlate similar-looking values (especially taking the fees into account). - -### Project Details - -Conceptually, the project is similar to an Ethereum-based [tornado.cash](https://tornado.cash/). We won't describe the mechanics of that project in this application, but rather outline the differences in implementation and how it will translate to a Polkadot deployment. - -1. ZK Proof system -Tornado cash uses a Groth16 proving scheme, whereas this proposal will leverage a more modern and efficient scheme Plonk. -The three main advantages of Plonk over Groth16 are: -* Faster prover time -* Smaller number of circuit constraints[^1], leading to smaller program sizes -* Trusted setup, while still required, is universal (not relevant for this project) -[^1]: for a concrete circuit proving leaf knowledge in a Merkle tree, which is essential for any mixer -2. Hash function -The advantage of building an end-product after Tornado is the opportunity to use newer hash functions, too. Specifically, we will be using a Poseidon hash function, which is more suited for ZK proof systems than Pedersen hash used in Tornado, using up to 8x less constraints per message bit [^2]. -[^2]: [Poseidon Hash paper](https://eprint.iacr.org/2019/458.pdf) -3. Implementation -While we could build the smart contract with solidity and deploy on an EVM-compatible parachain, we believe that using a rust-based smart contract language brings unquestionable security benefits to the table. -There are Rust-based implementations already available of both [Plonk](https://github.com/dusk-network/plonk) and [Poseidon Hash](https://github.com/dusk-network/Poseidon252/). In the scope of this project, we will reuse those implementations in ink!-based smart contracts to build a usable product. -Aside from the core protocol (smart contracts), there are two more critical components to make it fully functional: - 1. Tx Relayer: the whole idea of a mixer is that the withdrawing account can't be linked to the deposit account. This means withdrawing from an empty account which can't cover its Tx fees. This is where the relayer comes in: a user would generate the proof in the frontend portal with their own payout address and relayer's fee address as parameters, so that the relayer can't steal the funds. The relayer submits the Tx to the smart contract, which, upon verifying the correctness, would pay the amount to the user and a subtract the fee for the relayer. - 2. Frontend: users should have a friendly interface (akin to Tornado.cash) to: - - create commitments and submit them to the mixer. They should be presented with a "note" that allows them to withdraw the amount later - - select the relayer - - spend the notes, by submitting the necessary data to the contract for it to verify the ownership of the deposited coin - -The end goal of this grant is a deployed set of smart contracts on some ink!-supporting testnet (like [Shibuya](https://shibuya.subscan.io/)) and a deployed Relayer. -Since this grant only covers smart contracts, CLI & relayer development, we plan to include the frontend into the follow-up grant application, which would turn this set of smart contracts into a user-friendly application. - -### Ecosystem Fit -The project closest to ours is [anon](https://github.com/webb-tools/anon). They are building a mixer as a substrate module as opposed to smart contracts. Furthermore, they are utilizing the Bulletproofs system in contrast to Plonk. - -## Development Roadmap :nut_and_bolt: -### Overview -* **Total Estimated Duration:** 3 months -* **Full-Time Equivalent (FTE):** 1 - -### Milestone 1: ink! contract with Poseidon-based MerkleTree storage -* **Estimated duration:** 0.5 month -* **FTE:** 1 -* **Cost:** 5000 USDT -1. Create an `ink!` contract with `deposit` function, that uses the MerkleTree as the underlying data storage and appends the commitments "deposited" to it. The MerkleTree will use some Poseidon implementation (e.g., [neptune](https://github.com/filecoin-project/neptune), [poseidon252](https://github.com/dusk-network/Poseidon252) or alike). -2. Add the signature for the `withdraw` function. Verify that the submitted nullifier hash hasn't been "spent" yet. -3. Emit the `Deposit` and `Withdraw` events. -### Milestone 2: Plonk prover CLI tool (compiles to WASM) -* **Estimated duration:** 1 month -* **FTE:** 1 -* **Cost:** 10000 USDT - -Create a CLI tool that takes as inputs: -- the prover key `d_p`(hardcoded for now; later generated from a trusted setup ceremony) -- leaf index `l` -- the merkle tree opening for leaf `l` and a root `R` from history -- nullifier `k` -- randomness `r` -- payout address `A` -- relayer address `t` -- relayer fee `f` -And produces a ZK proof `P`. The tool can be compiled to WASM for future inclusion in the frontend component. -As [Dusk's Plonk implementation](https://github.com/dusk-network/plonk) already compiles to WASM, the only thing left is to write the code that constructs Zero-Knowledge proofs according to our input parameters. -### Milestone 3: `withdraw` method & Plonk verifier in `ink!` -* **Estimated duration:** 1 month -* **FTE:** 1 -* **Cost:** 10000 USDT - -To withdraw a coin, a user needs to submit a proof that they know the randomness & nullifier, i.e. they are the true owners of the coin. -The `withdraw` method of the mixer ensures that the nullifier `k` has not been spent yet (by storing the previously spent nullifier hashes). -Critically, the method delegates the checking of the proof to the verifier (another method), which takes as inputs: -- the verifier key `d_v` (hardcoded for now; later generated from a trusted setup ceremony) -- ZK Proof `P` generated by the prover -- Root `R` -- hash `h` of the nullifier `k` -- payout address `A` -- relayer address `t` -- relayer fee `f` -It returns true if the proof `P` satisfies the public values (the rest of the inputs) -We will utilise [Dusk's Plonk implementation](https://github.com/dusk-network/plonk) to do the verification for us. -### Milestone 4: Relayer -* **Estimated duration:** 0.5 month -* **FTE:** 1 -* **Cost:** 5000 USDT - -An offline tool (written in Rust) that is pre-funded and accepts incoming requests. -It verifies the validity of the submitted proof & Tx. If correct, it submits the Tx to the `ink!` contract (using `subxt`, `substrate-api-client` or other crates). -Also here we will write out the smart contract logic for paying out the fee `f` to relayer address `t`, once a valid Tx has been submitted. This will fall under the `withdraw` method. - -## Future Plans -Frontend application development, Trusted setup ceremony, potential integration with big DeFi ecosystem projects to allow private transactions - -## Team :busts_in_silhouette: - -### Team members -**Kyrylo Gorokhovskyi** (CTO and Blockchain solution architect) -**Volodymyr Antonov** (Blockchain Rust Engineer) -**Nino Lipartia** (Cryptography Engineer, Rust Engineer) - - -### Contact -* **Contact Name:** Kyrylo Gorokhovskyi -* **Contact Email:** k.gorokhovskyi@4irelabs.com -* **Website:** https://4irelabs.com - -### Legal Structure -* **Registered Address:** Tallinn, Kesklinna linnaosa, Tuukri tn 19-315, 10152, Estonia -* **Registered Legal Entity:** 4ire DApps OU - -### Team Code Repos -* https://github.com/4IRE-Labs -* https://github.com/Kyrylog -* https://github.com/azazak123 -* https://github.com/NinoLipartiia4ire - - -### Team LinkedIn Profiles (if available) -* https://www.linkedin.com/mwlite/in/kyrylo-gorokhovskyi-9b33701 -* https://www.linkedin.com/mwlite/in/nino-lipartiia-428302236 - -## Development Status :open_book: -The project is on internal discovery phase. - -## Development Roadmap :nut_and_bolt: - -### Overview -**We have decided to describe a full roadmap of the Slushie project here, with estimates.** - -* **Total Estimated Duration:** 3 months -* **Full-Time Equivalent (FTE):** 1 -* **Total Costs:** 30000 USDT - -### Milestone 1 - ink! contract with Poseidon-based MerkleTree storage -**Duration:** 0.5 months -**Costs:** 5000 USDT -**Programming languages:** ink!, Rust - -| Number | Deliverable | Specification | -| -----: | ----------- | ------------- | -| 0a. | License | MPL-2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and a README with the details used libraries & contract structure. | -| 0c. | Tests | The tests will be presented as unit tests, and instructions on how to run them will be referenced in the README file. | -| 1. | ink! contract with MerkleTree storage | Create an ink! contract that stores internal data (commits, nullifiers, etc.) as a Merkle Tree, add signature for "deposit" function | -| 2. | Change hash type of the Merkle Tree to some Poseidon implementation | Change hash type for the Merkle Tree to some Poseidon implementation (Dusk's [Poseidon252](https://github.com/dusk-network/poseidon252), [Neptune](https://github.com/filecoin-project/neptune)) | -| 3. | Withdraw function signature | Add the signature for the withdraw function. Verify that the submitted nullifier hash hasn’t been “spent” yet. | -| 4. | Add events | Emit the Deposit and Withdraw events. | - - -### Milestone 2 - Plonk prover CLI tool (compiles to WASM) - -**Duration:** 1 month -**Costs:** 10000 USDT -**Programming languages:** Rust - -| Number | Deliverable | Specification | -| -----: | ----------- | ------------- | -| 0a. | License | MPL-2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code. Also, we will provide the documentation for the CLI params, and the usage guide. | -| 0c. | Tests | The tests will be presented as unit tests, and instructions on how to run them will be referenced in the README file. | -| 1. | The CLI app | Create the CLI app to later include the proof generation logic | -| 2. | Proof production logic | Create Plonk proofs from the given data (prover key, randomness etc.) | - -### Milestone 3: `withdraw` method & Plonk verifier in `ink!` - -**Duration:** 1 month -**Costs:** 10000 USDT -**Programming languages:** ink!, Rust - -| Number | Deliverable | Specification | -| -----: | ----------- | ------------- | -| 0a. | License | MPL-2.0 | -| 0b. | Documentation | We will provide the inline documentation of the code and docs for the verifier separately. | -| 0c. | Tests | The tests will be presented as unit tests, integration tests using `polkadot.js` / `redspot` (TBD) and instructions on how to run them will be referenced in the README file. | -| 1. | Plonk verifier | ink! contract logic that verifies provided proofs | -| 2. | Withdrawal contract logic | Add contract logic for withdrawing coins and saving the used nullifier | - -### Milestone 4: Relayer - -**Duration:** 0.5 months -**Costs:** 5000 USDT -**Programming languages:** Rust - - -| Number | Deliverable | Specification | -| -----: | ----------- | ------------- | -| 0a. | License | MPL-2.0 | -| 0b. | Documentation | We will provide both inline documentation of the code and quick walk-through of the service. | -| 0c. | Tests | The tests will be presented as unit tests, and instructions on how to run them will be referenced in the README file. | -| 1. | Relayer service | Service for validating transactions and proofs and relaying them to the blockchain for a fee | -| 2. | Fee logic | Change in a contract to pay a fee to the relayer from the transferred funds directly | - -### Current work - Scope of this Grant -## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** Personal recommendation diff --git a/applications/Societal.md b/applications/Societal.md index 7768b9a93d5..739a0e48b06 100644 --- a/applications/Societal.md +++ b/applications/Societal.md @@ -1,12 +1,11 @@ -# W3F Grant Proposal +# Societal - MVP - Phase 1 -- **Project Name:** Societal - MVP - Phase 1 - **Team Name:** Societal Labs Ltd. -- **Payment Address:** Ethereum - USDT: 0x80243a916c9ff4837734FE3248d8641476280824 -- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 +- **Payment Address:** Ethereum - USDT: 0xcDcCF94f10d8A7165C1A336DD3795430a6CDE530 +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 -## Project Overview :page_facing_up: +## Project Overview ### Overview @@ -14,24 +13,25 @@ Societal is an all-in-one Decentralized Autonomous Organization (DAO) creation a Utilizing Polkdaot’s layer-0 infrastructure and ecosystem, Societal will provide DAOs with both maximum functionality and a cohesive user experience. With features including agnostic token compatibility, zero gas fees, a freemium entry point, and a SaaS-based membership pricing, Societal combines best-in-class features into one vertically integrated product. With integrations into DeFi, privacy, and identity protocols, Societal will enable web3 organizations to seamlessly transition and manage their DAOs into the future. -The Societal team has been building in the Polkadot ecosystem for the last year. While at a previous Polkadot project, the Societal team noticed a lack of integrated DAO tooling - not only in the Polkadot ecosystem, but in the broader web3 industry as a whole. After analyzing how we might transition and manage our previous project into a DAO, there was no clear path. This, along with the team being both members and council members of various DAOs and noticing the lack of infrastructure, we decided to build a solution - Societal. +The Societal team has been building in the Polkadot ecosystem for the last year. While at a previous Polkadot project, the Societal team noticed a lack of integrated DAO tooling - not only in the Polkadot ecosystem, but in the broader web3 industry as a whole. After analyzing how we might transition and manage our previous project into a DAO, there was no clear path. This, along with the team being both members and council members of various DAOs and noticing the lack of infrastructure, we decided to build a solution - Societal. ### Project Details -Societal Labs has been designing the product vision of the Socital platform for quite some time. We will go over the project details and blockchain architecture in this application and provide references below for more in-depth context. +Societal Labs has been designing the product vision of the Socital platform for quite some time. We will go over the project details and blockchain architecture in this application and provide references below for more in-depth context. -In Societal's final state, it will offer four main services; Create, Transition, Transfer and Manage. Create will allow any web3 user to create their own DAO. Transition will allow protocols to progressively move towards community ownership. Transfer will allow DAOs to transfer their DAO from an expensive siloed chain to the Sociteal platform. Manage will provide DAOs all the required product features to manage their organization, whether it is a small investment club or a large community-governed protocol. +In Societal's final state, it will offer four main services; Create, Transition, Transfer and Manage. Create will allow any web3 user to create their own DAO. Transition will allow protocols to progressively move towards community ownership. Transfer will allow DAOs to transfer their DAO from an expensive siloed chain to the Sociteal platform. Manage will provide DAOs all the required product features to manage their organization, whether it is a small investment club or a large community-governed protocol. -Societal will offer a wide range of features to create and manage a DAO. The features are split into three categories; Operations, Treasury, and Governance. The Operations features are: job & task boards, payroll, customizable feeds, legal tooling, on-chain reputation, and web & mobile application. The Treasury features are as follows: treasury wallets (multi-sig), DeFi integrations, on-chain cap table, accounting and private asset integrations. The governance features are: zero gas fee governance, proposal calendar, built-in governance models, governance treasury execution, and private voting. +Societal will offer a wide range of features to create and manage a DAO. The features are split into three categories; Operations, Treasury, and Governance. The Operations features are: job & task boards, payroll, customizable feeds, legal tooling, on-chain reputation, and web & mobile application. The Treasury features are as follows: treasury wallets (multi-sig), DeFi integrations, on-chain cap table, accounting and private asset integrations. The governance features are: zero gas fee governance, proposal calendar, built-in governance models, governance treasury execution, and private voting. -Societal will vertically integrate with projects to advance its tech stack and product offering, something not seen in most web3 projects today. For example, Societal can integrate DeFi services by working with projects like Acala, Parallel, and Composable Finance, which will allow for active treasury management for DAOs managed with Societal. For private assets and voting, projects like Manta and Phala can provide privacy-enabling functions like zero-knowledge proofs and trusted execution environments to make this possible. For on-chain credentials, projects like KILT and Litentry can provide KYC and member credentialing services that can be used by DAOs for governance and recruiting. +Societal will vertically integrate with projects to advance its tech stack and product offering, something not seen in most web3 projects today. For example, Societal can integrate DeFi services by working with projects like Acala, Parallel, and Composable Finance, which will allow for active treasury management for DAOs managed with Societal. For private assets and voting, projects like Manta and Phala can provide privacy-enabling functions like zero-knowledge proofs and trusted execution environments to make this possible. For on-chain credentials, projects like KILT and Litentry can provide KYC and member credentialing services that can be used by DAOs for governance and recruiting. The Societal platform will host a vast network of DAOs and eventually offer a Cross-DAO Marketplace. DAO’s onboarded onto the platform will have access to a network of individual DAOs, along with any associated sub-DAOs or guilds. When a DAO has a task that needs to be completed, they will have the ability to post this task to the entire Societal network. This will reach the collective network of sub-DAOs or guilds that may have the ability to complete the required work. The interconnection of DAOs on the Societal platform will open up never before seen opportunities in collaboration across the web3 DAO, sub-DAO, and guild ecosystem. -Finally, Societal plans to progressively transition into a DAO itself. Once the token is launched, a community-run treasury will grow over time until the entire network is owned and operated by the community. +Finally, Societal plans to progressively transition into a DAO itself. Once the token is launched, a community-run treasury will grow over time until the entire network is owned and operated by the community. For more information, please refer to the following resources: + - Societal Whitepaper [here](https://docsend.com/view/2gte2fd8wc4jp4rg) - Societal Docs [here](https://docs.sctl.xyz/) - Societal Testnet Requirements Doc [here](https://docs.google.com/document/d/1seqVIZC-KDVe0ZAdPD1eb8WLKkpirMGB0CcM61eRq3k/edit) @@ -52,29 +52,28 @@ UI Mockups: As it stands today, the DAO landscape within the Polkadot ecosystem is not as mature as other ecosystems such as Ethereum and Solana. This is due to insufficient DAO creation and tooling infrastructure in the ecosystem. Currently, the Polkadot ecosystem does not have the creation, governance, treasury management, and payroll tooling products as other major blockchains. By building these tooling products on Polkadot, both the Polkadot DAO landscape and the broader DAO management tooling space is primed for innovation by utilizing the unique technical abilities that Substrate provides. -The target audience of the Societal application are web3 users who require a platform to easily create and manage their DAO. Using the technical capabilities that Substrate provides, Societal will design our chain to be token agnostic, allowing current MetaMask users to easily connect to our chain and start using the governance application right away. By doing this, our project will meet the needs of the Polkadot community to create their own DAOs and have the tools to manage them as seen in other ecosystems. +The target audience of the Societal application are web3 users who require a platform to easily create and manage their DAO. Using the technical capabilities that Substrate provides, Societal will design our chain to be token agnostic, allowing current MetaMask users to easily connect to our chain and start using the governance application right away. By doing this, our project will meet the needs of the Polkadot community to create their own DAOs and have the tools to manage them as seen in other ecosystems. -The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and DoraFactory. Societal differs from these projects in multiple ways. First, Polkassembly is not building their own parachain and is only a governance platform for large Polkadot projects. Societal wants to allow any web3 user to create their own DAO - not just catering to large established protocols. SubDAO has recently been focusing on smart contract deployments on multiple chains and does not appear to be building a parachain. Societal will build its own parachain and use the technical capabilities of Substrate to be truly token agnostic, connecting with widely used wallets such as MetaMask, to avoid doing multiple chain deployments via smart contracts. Dora Factory is similar to Societal in the sense that they are building their own parachian, however we plan to offer zero gas fees and a SaaS based pricing model to enhance our user's experience. Societal will also seek to integrate with other parachains, having cross-chain smart contract execution. +The projects like Societal in the Polkadot space are Polkassembly, SubDAO, and DoraFactory. Societal differs from these projects in multiple ways. First, Polkassembly is not building their own parachain and is only a governance platform for large Polkadot projects. Societal wants to allow any web3 user to create their own DAO - not just catering to large established protocols. SubDAO has recently been focusing on smart contract deployments on multiple chains and does not appear to be building a parachain. Societal will build its own parachain and use the technical capabilities of Substrate to be truly token agnostic, connecting with widely used wallets such as MetaMask, to avoid doing multiple chain deployments via smart contracts. Dora Factory is similar to Societal in the sense that they are building their own parachian, however we plan to offer zero gas fees and a SaaS based pricing model to enhance our user's experience. Societal will also seek to integrate with other parachains, having cross-chain smart contract execution. -## Team :busts_in_silhouette: +## Team ### Team members - Graeme Fox - Tyler Gellatly -- Kim Fournier - Max Kudinov ### Contact - **Contact Name:** Graeme Fox - **Contact Email:** graeme@sctl.xyz -- **Website:** sctl.xyz (Website still in development at time of application submission) +- **Website:** https://www.sctl.xyz/ ### Legal Structure - **Registered Address:** 707 5 St SW Unit 500, Calgary, AB, Canada T2P 0Y3 -- **Registered Legal Entity:** Societal Labs Ltd. +- **Registered Legal Entity:** Societal Labs Ltd. ### Team's experience @@ -82,18 +81,18 @@ Graeme Fox is the former Director of Business Development at Ruby Protocol, a pr Tyler Gellatly has been building and scaling early stage start-ups for the last 4+ years. He was employee #1 and Director of Operations & Partnerships at Cuboh (a YC-backed SAAS middleware operating within the ghost kitchen industry) More recently, Tyler helped found Ruby Protocol, a novel privacy protocol building on the Substrate framework, and is still involved in a strategic advisory capacity. Currently, he sits on the DAO council for the Illuminati Collective, which currently has a 1000 ETH treasury under management. Tyler holds a Bachelor of Commerce from the University of Victoria, specializing in corporate strategy and finance. A well-rounded business operations leader with a background in finance, operations, capital fundraising, and strategic partnerships, Tyler is mission driven to bring web3 communities together at scale by utilizing blockchain technology. -Kim Fournier is an advocate for blockchain marketing and is passionate about the intersection of decentralization and the future of work. She excels at crafting strong brand narratives to help organizations scale, and has led successful product releases, working with some of the world's top companies and fastest-growing startups both in and outside the blockchain space, including five Layer1 chains. She is an active member of the NFT community, as well as CryptoFemmes and Women in Blockchain. - -Max Kudinov is the CEO of Magic Powered, a software development firm building multiple web3 projects. Max has a passion for governance projects and was the Project Lead for the development of [Astro DAO](https://astrodao.com/), an all-in-one DAO creation and management platform built on Near. From this experience, Max has excellent understanding of Rust and how he would like to improve upon the Astro DAO project. Max has highly experienced web3 and rust developers on his team, ready to start the development of this project. +Max Kudinov is the CEO of Magic Powered, a software development firm building multiple web3 projects. Max has a passion for governance projects and was the Project Lead for the development of [Astro DAO](https://astrodao.com/), an all-in-one DAO creation and management platform built on Near. From this experience, Max has excellent understanding of Rust and how he would like to improve upon the Astro DAO project. Max has highly experienced web3 and rust developers on his team, ready to start the development of this project. ### Team Code Repos Org: + - https://github.com/sctllabs Please also provide the GitHub accounts of all team members. If they contain no activity, references to projects hosted elsewhere or live are also fine. Team: + - https://github.com/gfox1 - https://github.com/near-daos - https://github.com/near-daos/astro-ui @@ -103,11 +102,10 @@ Team: ### Team LinkedIn Profiles (if available) - https://www.linkedin.com/in/graemefox/ -- https://www.linkedin.com/in/kimjfournier/ - https://www.linkedin.com/in/tngell/ - https://www.linkedin.com/in/max-kudinov-395595152/ -## Development Status :open_book: +## Development Status Before applying for the Web3 Foundation Grant, the Societal team conducted the following research: @@ -121,37 +119,36 @@ Before applying for the Web3 Foundation Grant, the Societal team conducted the f ### Overview - **Total Estimated Duration:** 4 months -- **Full-Time Equivalent (FTE):** 3 FTE -- **Total Costs:** 40,000 USDT +- **Full-Time Equivalent (FTE):** 3 FTE +- **Total Costs:** 30,000 USDT + -### Milestone 1 — Governance & Treasury Dashboard +### Milestone 1 — DAO Factory Pallet -- **Estimated duration:** 1 month +- **Estimated Duration:** 2 months - **FTE:** 3 -- **Costs:** 10,000 USD +- **Costs:** 20,000 USD -The main delivery of this milestone is to have an easy to use and interactive dashboard for DAOs to manage their governance and treasury. +The main delivery of this milestone will be the DAO Factory Pallet. This pallet will allow someone to create a DAO on the Societal Network, where the DAO consists of a governance token, treasury and governance system. | Number | Deliverable | Specification | | -----: | ----------- | ------------- | | 0a. | License | Apache 2.0 | -| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | +| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and create a DAO. | | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 0e. | Article | We will publish a tutorial that explains the UI of the Societal platform and how to use the application. | -| 1. | Client Modules | We will create a client facing UI that will interact with the Societal chain. The main function of the dashboard will be a for governance and treasury management. | -| 2. | Substrate chain | In this milestone the Substrate chain will be built and the necessary pallets will be implemented. The pallets that will be included are: System, Support, Executive, Assets, Authority Discovery, BABE, Balances, Democracy, Elections, Referenda, GRANDPA, Indices, Membership, Multisig, Nicks, Proxy, Scheduler, Transaction Payment, and Treasury | - -Notes: Please note that the list of pallets is not exhausted. Some pallets may need to be added or removed from the MVP. However, based on my initial research the pallets listed above will be the required pallets for the Societal chain. +| 0e. | Article | We will publish a tutorial that explains how to create a DAO. | +| 1. | Substrate module: DAO Factory | This substrate pallet will create a DAO. While creating a DAO, the user can create a token for the DAO, setup a treasury and select a governance system. | +| 2. | Client Modules | Minor UI updates will be made, to allow the user to interact with the pallet. However, the major UI creation will be completed in milestone 2. | -### Milestone 2 — Cross-Chain Smart Contract Execution via an Approved Governance Proposal +### Milestone 2 — Governance & Treasury Dashboard -- **Estimated Duration:** 1.5 months +- **Estimated duration:** 2 months - **FTE:** 3 -- **Costs:** 15,000 USD +- **Costs:** 10,000 USD -The main delivery of this milestone will allow an approved governance proposal on the Societal chain to execute a smart contract on Moonbeam Alpha TestNet. The delivery will also include minor UI updates, to allow the user to interact with the pallet. +The main delivery of this milestone is to have an easy to use and interactive UI for users to create a DAO and manage its governance and treasury. | Number | Deliverable | Specification | | -----: | ----------- | ------------- | @@ -159,48 +156,23 @@ The main delivery of this milestone will allow an approved governance proposal o | 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | | 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | | 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 0e. | Article | We will publish a tutorial that explains how to setup a governance proposal that will execute contracts cross-chain. | -| 1. | Substrate module: Governance Execution | This substrate module will be a loosely coupled pallet to the existing governance pallet. We will make this into a separate pallet to allow for governance proposals to take place that do not require a smart contact to execute after approval. | -| 2. | Client Modules | Minor UI updates will be made, to allow the user to interact with the pallet. | - -Notes: -- This will be created for Moonbeam's testnet - Moonbase Alpha, so we do not have to win a parachain slot before testing the pallet -- An HRMP channel will need to be established between Societal’s testnet and Moonbase Alpha to sucessfully complete this milesotne -- This milestone assumes that it will be better to create a new pallet that allows for the smart contract execution on another chain, which works in conjunction with the existing governance pallets such as the democracy, elections or referenda pallets. However, a modification to the existing governance pallets may be all that is necessary and a better design. - -### Milestone 3 — SaaS Pricing Model Pallet - -- **Estimated Duration:** 1.5 month -- **FTE:** 3 -- **Costs:** 15,000 USD +| 0e. | Article | We will publish a tutorial that explains the UI of the Societal platform and how to use the application. | +| 1. | Client Modules | We will create a client facing UI that will interact with the Societal chain. The main function of the dashboard will be for the creation of the DAO, and manage its goverance & treasury. | +| 2. | Substrate chain | In this milestone the Substrate chain will be built and the necessary pallets will be implemented. The pallets that will be included are: DAO FACTORY, System, Support, Executive, Assets, Authority Discovery, BABE, Balances, Democracy, Elections, Referenda, GRANDPA, Indices, Membership, Multisig, Nicks, Proxy, Scheduler, Transaction Payment, and Treasury | -The main delivery of this milestone will be the creation of a 'SaaS' Pricing pallet. Transactions on the Societal chain will always be free to the user for the creation of proposals and voting on proposals. However, once the DAO is large enough or requires certain functions, the Societal platform will require monthly payments for those features, which will come directly from the DAOs treasury. This will bring current web2 pricing models to web3, increasing user experience and ease of adoption. An overview of the initial plans can be found [here](https://docs.sctl.xyz/societal-platform/pricing). The delivery will also include minor UI updates, to allow the user to interact with the pallet. +Notes: Please note that the list of pallets is not exhausted. Some pallets may need to be added or removed from the MVP. However, based on my initial research the pallets listed above will be the required pallets for the Societal chain. -| Number | Deliverable | Specification | -| -----: | ----------- | ------------- | -| 0a. | License | Apache 2.0 | -| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a user can (for example) spin up one of our Substrate nodes and send test transactions, which will show how the new functionality works. | -| 0c. | Testing Guide | Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests. | -| 0d. | Docker | We will provide a Dockerfile(s) that can be used to test all the functionality delivered with this milestone. | -| 0e. | Article | We will publish an article that gives an overview of the pricing plans and the features that are associated with each plan. | -| 1. | Substrate module: SaaS Pricing | We will create a Substrate module that will require DAOs to pay a monthly subscription fee if they want to have a certain number of users in their DAO or access to certain functions. The payment for the monthly subscriptions will come directly from the DAOs wallet and not the individual members. Transactions on the Societal platform will always be free for the individual users for the creation of proposals and voting on proposals. | -| 2. | Client Modules | Minor UI updates will be made, to allow the user to interact with the pallet. | -Implementation notes: -- To make this work, the SaaS pricing pallet would do the following: - - First, it will check how many members are in the DAO via how many holders there are of the DAO token. - - Second, it would have to check if the DAO has made a monthly payment from one of its wallets to the Societal subscriptions wallet. - - Based on the answer to these questions, the UI would display certain functions to the DAO users on their dashboard. ## Future Plans -Societal plans to secure fundraising and expand the development team. After the completion of the milestones stated above, Societal plans to expand the product offering by implementing a DAO Market Place and a Mobile App for DAO management. Ideally Societal will be able to secure another Web3 grant for these milestones, along with integrations for [private voting](https://github.com/w3f/Grants-Program/blob/master/rfps/anti-collusion%20infrastructure.md) and [identity voting](https://github.com/w3f/Grants-Program/blob/master/rfps/identity-directory.md) based on links to the RFPs. From there, Societal would also like to apply for the Substrate Builders Program, establishing itself at the go to DAO and governance platform. Finally, Societal will progressively transition into a DAO itself and release control to the community. +Societal plans to secure fundraising and expand the development team. After the completion of the milestones stated above, Societal plans to expand the product offering by implementing a DAO Market Place and a Mobile App for DAO management. Ideally Societal will be able to secure another Web3 grant for these milestones, along with integrations for [private voting](https://github.com/w3f/Grants-Program/blob/master/rfps/anti-collusion%20infrastructure.md) and [identity voting](https://github.com/w3f/Grants-Program/blob/master/rfps/identity-directory.md) based on links to the RFPs. From there, Societal would also like to apply for the Substrate Builders Program, establishing itself at the go to DAO and governance platform. Finally, Societal will progressively transition into a DAO itself and release control to the community. -## Additional Information :heavy_plus_sign: +## Additional Information -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** Societal heard about the Grants Program from our time building in the Polkadot Ecosystem. @@ -213,4 +185,4 @@ Additional Information: - Yes, all the founders of Societal Labs have contributed financially to the project. - Previous grants you may have applied for? - - No other grants have been applied for. + - No other grants have been applied for. diff --git a/applications/Solang_Playground.md b/applications/Solang_Playground.md new file mode 100644 index 00000000000..8c6a7f0f26b --- /dev/null +++ b/applications/Solang_Playground.md @@ -0,0 +1,264 @@ +# Solang Playground + + +- **Team Name:** Salaheldin Soliman and Tarek Elsayed +- **Payment Address:** + - Salaheldin Soliman: 0x9036b20920ddf473e796d24afd0fe04d4dde0b68 + - Tarek Elsayed: 0xA91584056eEB860147158c7cC90818D3f5039014 +- **Payment Details:** DAI (ERC20) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 + + +## Project Overview :page_facing_up: + +This application is a follow-up grant for this [grant](https://github.com/w3f/Grants-Program/blob/master/applications/Solang_developer_experience_improvements.md). The main theme is improving Solidity developer experience on non-EVM chains. + +### Overview + +Solang compiles Solidity smart contracts to Substrate and Solana targets. An in-depth overview of Solang's purpose and motivation can be found at https://hyperledger.github.io/hyperledger-hip/HIPs/solang.html. + +Solang Playground will be a web based IDE that allows users to compile and interact with Solidity smart contracts in a browser environment, without prior installation of any of the needed components: `Solang`or `Substrate contracts node`. The aim here is to provide an experience similar to what [Remix IDE](https://remix.ethereum.org/) provides, as Remix is the first tool Solidity developers get introduced to in their smart contract learning track. + + +### Project Details +The aim of this project is to implement a web based IDE for Solang, and continue to improve it until full maturity. Therefore, improving Solidity developer experience on Substrate based chains through undertaking the following milestones: + +#### First Milestone: Solang's language server integrated in a Solidity Web Editor Client + +##### Task 1: Language server package +As of now, `Solang` has a builtin language server. That is, the language server is a subcommand of the Solang executable. If the language server code is separated from Solang, in a standalone crate, and compiled to `wasm`, it should be able to run in a browser environment. +Compiling Solang as a whole to `wasm` would be a more challenging task since its dependence on `LLVM`, so this would be considered as a future improvement to the IDE. +The aim of this task is to develop a version of Solang's language server that could be compiled to `wasm`, and could be integrated to a web code editor. + + +##### Task 2: The Web IDE client. +Now that the language server `wasm` executable is ready from task one, we are ready to integrate it to a front-end which will provide the following functionalities: +1- uses `Monaco editor` to edit `solidity` and `.toml` files. +2- uses the `wasm` Solang language server to improve Solidity code editing experience. + +At this point, the client should take its initial design: A simple web IDE with a file explorer and a code editor +![](https://hackmd.io/_uploads/Sy8wDpAi2.jpg) + +###### Note: This is a mock UI where Solidity code is not hinted by the language server. At the end of the project, there would be a section showing the deployed contracts and how to interact with them. + +#### Second Milestone: Solang Playground Backend Service + +The aim of this milestone is to develop a back-end server that is responsible for the following: +1- Compile Solidity source files. +2- Return Compiled byte-code as well as contracts metadata to the client (front-end) + +To achieve this functionality, the server will host the following: +1- Solang Compiler docker image. + +The back-end server will be built using the `actix framework`. + +In the end of this milestone, the client should be able to interact with the back-end server, and the architecture will look like this: +![](https://hackmd.io/_uploads/ByjxjgFjh.png) + +At this point in the project, The client should be able to save and edit Solidity source files, compile them and save the compiled byte-code and metadata. + + + + +#### Third Milestone: Substrate contracts nodes interaction + + +##### Task 1: Investigate and integrate means for Substrate node interaction + +In order to deploy and interact with a smart contract, a run-time is needed (Substrate contracts pallet). Here are the existing options: + +1- Interact with a public test-net. + +2- There is [Drink](https://github.com/Cardinal-Cryptography/drink), which provides a minimal substrate run-time with a an interface to interact with. This Could be compiled to `wasm` and won't need to be hosted in the back-end server. + +3- Host a substrate contracts node on the back-end server. + +###### Note: My decision will be more inclined towards the first two options. The reason is that in the near future, `llvm` wasm package would be up-streamed and `Solang` can be compiled to `wasm` then. A future plan for the IDE is that it doesn't depend on any back-end service. + + +At the end of this milestone, the architecture will evolve into this: +![](https://hackmd.io/_uploads/HksDHFAoh.png) + + +The front-end will be responsible for providing language smarts from Solang's language server, and taking the following from the user and sending them to the Back-end: +1- Solidity source files +2- Compiler options + +The back-end will respond with compilation results: compiled bytecode and contracts metadata. The contracts will then be deployed and interacted with through scripts accessible to the client. The aim of this milestone is to merge milestones one and two, and to provide a test suite ensuring that front-end and back-end interactions are happening seamlessly. After this milestone, I will share blog posts and articles inviting Solidity developers to try out the IDE. + + +#### Fourth Milestone: IDE Improvements + +Remix IDE has some attractive functionalities to any solidity developer, which we would like to see on the Substrate side: + + +1- Calling a specific function by the click of a button, alongside with the required parameters. E.G. similar to `contracts UI`. (Only possible on the Substrate side) + +2- Initializing the work-space with an example contract in a `Solang project` file structure ready for deployment and interaction. + + +These functionalities will be implemented as a first step towards improving the IDE. + + + +#### Important Note: This grant will be more focused on achieving core functionality rather than making the IDE visually attractive. This would be considered as a future plan for improving the IDE. + + +### Ecosystem Fit + +- **Where and how does your project fit into the ecosystem? Who is your target audience? What need(s) does your project meet?** + +Quoted from the Ecosystem Fit section of the previous completed grant application, this statement still holds: "We still have a long way to go in terms of developer experience with Solidity on Substrate based chains. Although Solang as a compiler itself can be considered a huge step towards attracting solidity developers to the Polkadot/Kusama ecosystems: The Solidity developer experience on Ethereum far exceeds that of "Solidity Contracts on Substrate", caused by our inferior tooling and debugging story." + +The story stays the same, but the solution offered here is different: By Offering an `EVM` developer an easy portal to the Substrate echo-system, especially with the language they love (Solidity) alongside a fairly good IDE that will be comparable to Remix in the long run, Substrate based chains will be an easy to try option without any prior installation of any component. + +This project would benefit any para-chain using the `wasm` contracts pallet. + +- **Are there any other projects similar to yours in the Substrate / Polkadot / Kusama ecosystem?** + +Yes. There exists paritytech's [Ink! Playground](https://github.com/paritytech/ink-playground). As the name implies, Ink! Playground would compile and deploy ink! contracts, not Solidity. +As a matter of fact, I investigated integrating Solang to Ink! playground, but this implied two problems: +1- Changing the name of the project. (Not likely to take place) +2- Convincing the contributors to integrate Solana. (Not likely to take place) + + + +## Team :busts_in_silhouette: + +### Team members + +- **Salaheldin Soliman**: + - **Contact Email:** salaheldin_sameh@aucegypt.edu + - **Github Handle:** https://github.com/salaheldinsoliman + - **LinkedIn Profile:** https://www.linkedin.com/in/salaheldinsoliman/ +- **Tarek Elsayed**: + - **Contact Email:** tareknaser360@gmail.com + - **Github Handle:** https://github.com/tareknaser + - **LinkedIn Profile:** https://www.linkedin.com/in/tareknasser360/ + + +### Relevant experience + +#### Salaheldin Soliman + +1. Worked on Solang as part of the [Hyperledger Mentorship Program](https://wiki.hyperledger.org/display/INTERN). + - Implemented [array bounds checks optimization](https://solang.readthedocs.io/en/latest/code_gen_options.html#array-bound-checks-optimization). + - Implemented [multiplication overflow detection during runtime](https://github.com/hyperledger/solang/pull/988). + - Implemented [constant overflow detection during compilation](https://github.com/hyperledger/solang/pull/1024#ref-commit-baaa425). + - Improved [Solang's parser resilience](https://github.com/hyperledger/solang/pull/1068). + + +2- Worked on Solang as part of a previous W3F [grant](https://github.com/w3f/Grants-Program/blob/master/applications/Solang_developer_experience_improvements.md). + + +#### Tarek Elsayed + +1. Worked on Solang as part of the [Hyperledger Mentorship Program](https://wiki.hyperledger.org/display/INTERN). + - Refactored extrinsics operations from `cargo contract`, creating a dedicated crate for extrinsics. ([cargo-contract#1181](https://github.com/use-ink/cargo-contract/pull/1181), [cargo-contract#1213](https://github.com/use-ink/cargo-contract/pull/1213)) + - Developed [Solang Aqd](https://github.com/hyperledger/solang-aqd), a CLI tool for interacting with smart contracts on chain. + + +## Development Status :open_book: + +The project can be considered as a helper project for Hyperledger Solang. +Designing the milestone structure was based on some existing IDE structures and design choices. To achieve the desired result, various open-source projects will be integrated. +A list of these projects and their use are briefly documented in this [notion page](https://www.notion.so/Solang-Playground-dfe85d3493a943849af67991e56adbf2?pvs=12). + +There were also talks, via mail, with members from the foundation explaining interest in the project. + +## Development Roadmap :nut_and_bolt: + + +### Overview + +- **Total Estimated Duration:** 13 months +- **Full-Time Equivalent (FTE):** ~0.5 +- **Total Costs:** 25,000 USD +- **Start Date:** September 1, 2023 +- **Spare Period(time extension for unexpected events):** 4 months spare (1 for each milestone) +### Milestone 1: Solang’s language server integrated in a Solidity Web Editor Client + +- **Estimated duration:** 5 month +- **FTE:** 0.75 +- **Costs:** 10,000 USD + + +| Number | Deliverable | Specification | +| ------ | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | - We will provide both **inline documentation** of the client code and a readme that shows the build steps of the language server `.wasm` binary. | +| **0c.** | Testing and Testing Guide | - The functionalities of the `.wasm` language server will be tested against the existing test suite of the current language server to ensure robustness.
          - Evaluators can fire up the docker container locally and try to edit Solidity source files with smarts provided from the language server.| +| **0d.** | Docker | A docker image will be provided so that an evaluator can easily set it up an try out the client locally. | +| 0e. | Solang Playground Client | We will provide a functional web editor in which a developer can edit and save Solidity source files with the help of Solang's language server.(documented code base). | + + +###### Note: To make things clear, this milestone **only** invovles the integration of the language server into the client. It does not involve compiling or deploying contracts. + +### Milestone 2: Solang Playground Backend Service + +- **Estimated Duration:** 3 month +- **FTE:** 0.75 +- **Costs:** 6,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and a `readme` that shows how to run and interact with the actix web server. | +| **0c.** | Testing and Testing Guide | - Unit tests to be provided to test for the compilation result of the web server. The unit tests will be a part of the server's source code.
          - Test scripts for the client's compile functionality. | +| **0d.** | Docker | - A `Docker` container will be provided for the actix web server.
          - A `Docker compose` script to be provided to build both the client container and the backend container and set their networking. | +|1. | Initial skeleton | - The client should have a `compile` functionality in which the bytecode and metadata can be viewed. This would be done by the interaction with the backend server implemented in this milestone. | + + +### Milestone 3: Substrate node interaction + +- **Estimated Duration:** 3 month +- **FTE:** 0.5 +- **Costs:** 5,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | Added code to the client will be documented. Steps for deploying and interacting with a smart contract will also be provided at this point. | +| **0c.** | Testing and Testing Guide | - A testing suite will be provided to ensure that the front-end sends the correct requests `(compile, deploy and test)` with correct parameters. The tests will ensure the contracts are deployed and could be interacted with as expected. | +| **0d.** | Docker | Since this milestone is considered added functionality to the client `(milestone 1)`, the docker provided in the first milestone would be updated and a new container for the client will be provided. | +| 1. | First Working Version | - At this point, a Solidity developer should be able to edit, compile, deploy and interact with a smart contract through the IDE without installing any components.| + + +### Milestone 4 Solang IDE Improvements + +- **Estimated Duration:** 2 month +- **FTE:** 0.5 +- **Costs:** 4,000 USD + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | We will provide both **inline documentation** of the code and update the `readme` of the playground with the newly added functionalities | +| **0c.** | Testing and Testing Guide | The added functionality will be tested against the test suite provided in milestone 4 | +| **0d.** | Docker | Since this milestone is considered added functionality to the client `(milestone 1)`, the docker provided in the first milestone would be updated and a new container for the client will be provided. | +|**0e.** | Article | I will share a blog-post on multiple platforms inviting Solidity developers to try out Solidity on Substrate using the IDE.| +| 1.| IDE Improvements | 1- Call a specific function by the click of a button, alongside with the required parameters. E.G. similar to `contracts UI`. (Only possible on the Substrate side)
          2- Initializing the work-space with an example contract in a Solang project file structure ready for deployment and interaction. + + +## Future Plans + +### Future improvements + +#### 1- Removing the Backend Component: + +Removing the Back-end component of the web IDE consists of a collection of tasks: + +- Investigate compiling Solang to `wasm` to run in the browser. This will imply investigating a suitable way to compile `LLVM` to `wasm`. + +- There are implementations of mock Substrate contracts run-time, but they don't support full chain operations. Compiling the runtime with full functionality to `wasm` will be investigated. + + +#### 2- Making the IDE visually attractive + + + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +I have already completed a grant under this program. I was first introduced to it by my mentor [Sean Young](sean@mess.org) and the awesome [Cyrill leutwiler](bigcyrill@hotmail.com). \ No newline at end of file diff --git a/applications/Solang_developer_experience_improvements.md b/applications/Solang_developer_experience_improvements.md new file mode 100644 index 00000000000..60837b5c973 --- /dev/null +++ b/applications/Solang_developer_experience_improvements.md @@ -0,0 +1,140 @@ +# Solang developer experience improvements. + +- **Project Name:** Solang Maintenance + +- **Contributor Name:** Salaheldin Soliman + +- **Payment Details:** DAI (ERC20) + +- **Address**: 0x9036b20920ddf473e796d24afd0fe04d4dde0b68 + +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 1 + +## Project Overview :page_facing_up: + +### Overview + +Solang compiles Solidity smart contracts to Substrate and Solana targets. An in-depth overview of Solang's purpose and motivation can be found at https://hyperledger.github.io/hyperledger-hip/HIPs/solang.html. + +### Solang Improvement Project Details + +The aim of this project is to improve Solidity developer experience on Substrate chains through undertaking the following two milestones: + +- [lmprove debug buffer usage](https://github.com/hyperledger/solang/milestone/5): + + - The debug buffer can be used by the smart contract as a way to communicate with the developer during runtime, e.g. for printing messages or displaying the return code of API calls into the runtime environment. Currently, the debug buffer lacks any kind of structure, which can make for an awkward debugging experience. The goal is to use a JSON data structure within the debug buffer. This makes its usage more human friendly and even allows front-end tools to parse the content of the debug buffer in a defined way. + + - Currently, runtime errors are lost. Solang inserts an `unreachable` instruction, causing nothing more than a regular `trap` in case of runtime errors (like arithmetic overflows, failed assert statements, etc..). The aim here is to output the runtime error in the formatted debug buffer, so that a developer knows what went wrong (this doesn't even happen in Ethereum's Solc currently). The line number of the solidity source file in which that error is encountered will be displayed as a further improvement. + + - The debug buffer is not something meant to be used in production deployments (pallet contracts does not even support this in production setups). However, at the time of writing, `solang` does not have any means to omit all code generation related to the debug buffer. This results in (potentially a lot of) wasted gas. So another goal of this milestone is to implement a CLI flag for the compiler that effectively turns all logic related to debug printing into No-Op. + +- [Solang projects](https://github.com/hyperledger/solang/milestone/6): + + - At the time of writing, the only way to configure the compiler's behavior is to use CLI flags and options. An ever-growing list of compiler options (like optimization flags) and possible runtime configuration options is making this more and more awkward. This information can be provided to the compiler via a `TOML` file, similar to what we see in other languages (e.g. `Cargo.toml`). + + - To make this work, the compiler will need to implement functionality to parse its options out of such a `TOML` file. Additionally, some tooling should be implemented to help our users working with it. The first one will be a new sub-command `solang new`, which generates a new "Project" containing `Solang.toml` file with sensible defaults as well as some Solidity [flipper example](https://github.com/hyperledger/solang#simple-example) contract. Naturally, the `new` subcommand provides some configuration options itself, like specifying the project name or runtime target. + + - A further issue addressed here is that a Solidity developer using Solang currently has no way to tell the compiler some information like contract authors and version. Since this information is needed for metadata generation, it is just populated with some non-meaningful default value. As a consequence, at the time of writing, `solang` users need to edit the metadata file manually after each and every compilation. + + - Another improvement is for specifying the runtime target configuration. As-is, developers only have some low-level options like specifying the `address` and `balance` (`value`) size used by the runtime. A better solution would be able to provide high-level representations of currently deployed on-chain runtime configurations and the compiler will take care of the rest. For instance, providing a target configuration of "Substrate version `X`" or "pallet contract nodes version `Y`" will inform the compiler to generate contracts compatible with the default configuration of pallet contracts in substrate version `X` or contacts node version `Y` respectively. Other possible options for the user should be to just directly specify the parachain, e.g. `Rococo` or `Shiden` (randomly named examples). + +### Ecosystem Fit + +**Who is your target audience and how does your project fit into the ecosystem?** + +We still have a long way to go in terms of developer experience with Solidity on Substrate based chains. Although Solang as a compiler itself can be considered a huge step towards attracting solidity developers to the Polkadot/Kusama ecosystems: The Solidity developer experience on Ethereum far exceeds that of "Solidity Contracts on Substrate", caused by our inferior tooling and debugging story. The mentioned improvements are some immediate measures to address that. This grant will benefit any substrate parachain looking to leverage the possibility of using Solidity for their own good, as it will help level the developer experience for Solidity developers regardless whether they target Ethereum or Substrate. + +## Contributor :busts_in_silhouette: + +### Contact + +- **Contact Name:** Salaheldin Soliman + +- **Contact Email:** salaheldin_sameh@aucegypt.edu + +### Relevant Experience + +Worked on Solang as part of the [Hyperledger Mentorship Program](https://wiki.hyperledger.org/display/INTERN). + +1. Implemented [array bounds checks optimization](https://solang.readthedocs.io/en/latest/code_gen_options.html#array-bound-checks-optimization). +2. Implemented [multiplication overflow detection during runtime](https://github.com/hyperledger/solang/pull/988). +3. Implemented [constant overflow detection during compilation](https://github.com/hyperledger/solang/pull/1024#ref-commit-baaa425). +4. Improved [Solang's parser resilience](https://github.com/hyperledger/solang/pull/1068). + +### Github Handle + +- https://github.com/salaheldinsoliman + +### LinkedIn Profile + +- https://www.linkedin.com/in/salaheldinsoliman/ + +## Development Status 📖 + +This project is a part of larger repository: [Hyperledger Solang](https://github.com/hyperledger/solang). Solang is a Solidity compiler for Solana and Substrate, a formal documentation for the repo can be found at https://solang.readthedocs.io/en/latest/. + +There was no formal research done on the topic, but it can be noted that Solidity developer experience on Substrate chains is falling behind Ethereum's. Discussions with Solang's owner [Sean Young](sean@mess.org) and maintainer [Cyrill Leutwiler](cyrill@parity.io) , from Parity, have further solidified this statement. The above-mentioned tasks are a further step to alleviate this, through giving Solidity devs a smoother experience creating and debugging his contracts via Solang. + +## Development Roadmap 🔩 + +### Overview + +- **Start Date:** December 20, 2022 + +- **Estimated Duration:** 6 Months + 1 month spare. + +- **Sprint/Period Duration:** + First period(milestone): 4 months + Second period(milestone): 3 months + Grace period(Time allocated for events that are not pre-calculated, like emergencies or unexpected work): 1 month + +- **Full-Time Equivalent (FTE):** 0.5 FTE (20h per week) +- **Total Costs:** $5,000 + +### Milestone 1: Improve debug buffer usage + +- **Time Estimate**: 4 months +- **FTE (Full time Equivalent)**: 0.5 +- **Cost:** 3,000 USD + +| Number | Deliverable | Specification | +| ------: | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | I will provide both **inline documentation** of the code and some basic instructions of how a Solidity developer can utilize the debug buffer. I will also provide **documentation** of the newly added runtime errors. | +| **0c.** | Testing and Testing Guide | I will add unit tests to [Solang's Substrate integration tests](https://github.com/hyperledger/solang/tree/main/integration/substrate). The tests will ensure that the output of the omitted debug buffer is as expected(regarding prints, API calls, runtime errors and overall structure). Also, I will make sure that running Solang's test suite via `cargo test --workspace` produces no failing tests. | +| **0d.** | Docker | There will be no independent DockerFiler for this milestone, because Solang has its own DockerFile, which can be used to test the mentioned functionalities. | +| 1. | [Use structured data in the debug buffer](https://github.com/hyperledger/solang/issues/1048) | Completing this issue will result in a well structured debug buffer. | +| 2. | [Print execution errors in the debug buffer](https://github.com/hyperledger/solang/issues/1083) | Now that the debug buffer is well structured, runtime errors can be inserted in it for the user to debug. | +| 3. | [Execution errors to be passed with source file and line number](https://github.com/hyperledger/solang/issues/972) | Instead of having an arbitrary error emitted on the debug buffer, the line number of the instruction will be inserted so that the dev will have an easier debugging experience. | +| 4. | Bug Fix | Fix [Bug: Substrate Integration tests fail to compile with -g](https://github.com/hyperledger/solang/issues/1051) | + +### Milestone 2: Implement [Solang projects](https://github.com/hyperledger/solang/milestone/6): + +**Time Estimate:** 2 months +**FTE (Full time Equivalent):** 0.5 +**Cost:** 2,000 USD + +| Number | Deliverable | Specification | +| ------: | ------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **0a.** | License | Apache 2.0 | +| **0b.** | Documentation | I will provide both **inline documentation** of the code and some basic instructions of how a Solidity developer can utilize the command `solang new` and the `Solang.toml` file to provide compiler configuration | +| **0c.** | Testing and Testing Guide | I will add unit tests to [Solang's Substrate intergation tests](https://github.com/hyperledger/solang/tree/main/integration/substrate). The tests will ensure that the generated contract runs as expected on the configured chain. The tests will also ensure other information like contract author and version are correctly inserted the `Solang.toml`. | +| **0d.** | Docker | There will be no independent DockerFiler for this milestone, because Solang has its own DockerFile, which can be used to test the mentioned functionalities. | +| 0e. | Article | I will write a blog post that describes the two milestone, the target audience would be Solidity developers who want to try out Substrate. | +| 1. | Implement [Solang projects](https://github.com/hyperledger/solang/milestone/6) | The functionalities mentioned under `Solang Improvement Project Details: Solang Projects` will be delivered. | + +### Assurance That the Current Project Owners Are Willing to Review/Accept Your Contributions: + +Discussions with project owner [Sean Young](sean@mess.org) and maintainer [Cyrill Leutwiler](cyrill@parity.io) resulted in that the issues presented above would be reviewed and merged. + +## Current and Future Plans + +- Improve Substrate developer experience via the above-mentioned tasks +- Continue improving Solang till maturation from the Substrate side. +- Possibly develop an IDE based on Solang that matches Ethereum's Remix + +## Additional Information :heavy_plus_sign: + +**How did you hear about the Grants Program?** + +Recommendation from Solang's maintainers [Sean Young](sean@mess.org) and [Cyrill Leutwiler](cyrill@parity.io) diff --git a/applications/SpellRouter-proposal.md b/applications/SpellRouter-proposal.md new file mode 100644 index 00000000000..bedba935c46 --- /dev/null +++ b/applications/SpellRouter-proposal.md @@ -0,0 +1,302 @@ +# SpellRouter - XCM Router by ParaSpell✨ + +- **Team Name:** ParaSpell✨ +- **Payment Address:** FIAT (Shared 22.Dec.2023 14:56 via contact email mentioned in the application) +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 2 🐤 + +## Project Overview :page_facing_up: + +Previously completed grants: +- [Phase 1](https://github.com/w3f/Grants-Program/pull/1118) +- [Phase 2](https://github.com/w3f/Grants-Program/pull/1245) +- [Phase 3](https://github.com/w3f/Grants-Program/pull/1589) +- [LightSpell](https://github.com/w3f/Grants-Program/pull/1817) + +**What we do focus on in ParaSpell✨:** + +Our team has focused on the unification of cross-chain communication in the Polkadot and Kusama ecosystems for a while now. Our latest and flagship addition is XCM API also known as LightSpell⚡️. This tool allows you to implement cross-chain interoperability into your application within moments. ParaSpell offers a set of XCM & XCMP Developer tools meant to ease the integration of cross-chain functionality into dApps. As we have learnt by now, cross-chain experience between Parachains can be very diverse. ParaSpell means to unify this experience by doing all the research for developers. We have wrapped all XCM pallets from compatible nodes into simple patterns from which it is easy to create XCM calls. As an example, we provide the image below. + +![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/SpiderDAO.md b/applications/SpiderDAO.md index 3cf94fbb377..d3a81b81b1e 100644 --- a/applications/SpiderDAO.md +++ b/applications/SpiderDAO.md @@ -1,16 +1,18 @@ # SpiderDAO Grant Proposal + ![](https://i.imgur.com/zlw9lZ3.png) -* **Project:** SpiderDAO + * **Proposer:** [SpiderDAO] (https://github.com/SpiderDAO) * **Payment Address:** 3Pxq3ViqRW6b3e7qsX7Mo7gSikHcToa7ig * **Document Version:** Version 2.4 * **Status:** [Terminated](https://github.com/w3f/Grant-Milestone-Delivery/pull/129#issuecomment-1011987896) +## Project Overview :page_facing_up: -## Project Overview :page_facing_up: **SpiderDAO** is a next-generation hardware-based DAO governance model that aims to bring a new standard of fairness to existing DAO frameworks. Traditional DAO models are subject to attack and takeover by plutocracies controlled by wealthy whales. He who controls the votes controls the DAO. ### Overview + **SpiderDAO** is a unique governance infrastructure layer for a hardware-enabled DAO and can be applied in a variety of use cases. As the first use case, Spider will leverage its well-established presence in the hardware VPN market together with a partnership with Sentinel, an established dVPN provider and BPSAA Alliance member, to create a fully self-governing decentralized VPN network called SpiderVPN. We intend for SpiderDAO to run on its own Parachain on the Polkadot network. If the bond cannot be funded, the protocol will run on Parathreads or possibly as a series of smart contracts. Our initial testnet and protocol configuration will be built on Kusama and ported onto Polkadot for the mainnet launch. @@ -18,6 +20,7 @@ We intend for SpiderDAO to run on its own Parachain on the Polkadot network. If We believe that in order to fulfil the SpiderDAO’s vision of bringing greater privacy to the end-user, it is vital to establish a robust ecosystem that prioritises users’ interests. To do this, we must first establish a resilient, scalable and community-led governance system that dynamically adapts to the rapidly changing times. We believe that building a decentralised autonomous organisation is the perfect mechanism that will enable us to reach this goal. ### Project Details + ![](https://i.imgur.com/4y8BwFo.png) SpiderDAO’s long term vision is to propose a set of tools bringing privacy and security to today and tomorrow's internet users. To do so in an efficient and sustainable fashion, SpiderDAO’s team imagined and leveraged a robust DAO standard that will withstand the incredible adversity that such a mission implies. A first step is to address the plutocracy governance problem in traditional DAOs by introducing a set of rules that must be abided by to qualify for the right to an on-chain vote via the DAO. @@ -28,12 +31,12 @@ The SpiderConnect Hardware Router can be purchased by any community member, once ![](https://i.imgur.com/XFm46ql.png) - -**SpiderDAO** ecosystem brings together several other components to provide the building blocks for growing and sustaining a dynamic ecosystem. +**SpiderDAO** ecosystem brings together several other components to provide the building blocks for growing and sustaining a dynamic ecosystem. ![](https://i.imgur.com/AGJhoA5.png) **Spider Ecosystem will include:** + * SpiderDAO is the first hardware-governed DAO with a self-maintaining and self-improving robust Hardware/Software Governance control mechanism. * SpiderConnect Routers offer multiple roles as a high-speed VPN tunnel, a DAO voting ticket, and a node in a fully autonomous decentralised VPN. * SpiderVPN is a Virtual Private Network interlinking all the elements of the DAO & offering a complimentary dVPN service for qualifying users. @@ -43,71 +46,68 @@ The SpiderConnect Hardware Router can be purchased by any community member, once * **SpiderDashboard** (as seen Below) will provide an end-users access point to the features of the SpiderDAO. ![](https://i.imgur.com/UuanKdg.png) - - + ### Ecosystem Fit We see many projects in the Polkadot ecosystem that are having similar issues when it comes to voting system: MANTRA DAO is one of the examples. -The main problem with **Mantra DAO** which is built on **Rio Chain** is the same problem that many other DAOs faces where each token represent 1 vote in the ecosystem which introduces a major problem with the governing body where whales can take control of the DAO by buying big amounts of tokens making them in a way the deciding vote for any proposals. +The main problem with **Mantra DAO** which is built on **Rio Chain** is the same problem that many other DAOs faces where each token represent 1 vote in the ecosystem which introduces a major problem with the governing body where whales can take control of the DAO by buying big amounts of tokens making them in a way the deciding vote for any proposals. -### To solve this we intend to add the following features. +### To solve this we intend to add the following features **SpiderConnect Router Security** -- Our routers do have a secured ROM which we can control securely for all units and that's where the essential data will be saved. Our unique ID which currently contains the mac address & the router serial number will be combined with the wallet address and encrypted using our algorithm to make sure it would be nearly impossible to be compromised. +* Our routers do have a secured ROM which we can control securely for all units and that's where the essential data will be saved. Our unique ID which currently contains the mac address & the router serial number will be combined with the wallet address and encrypted using our algorithm to make sure it would be nearly impossible to be compromised. **Whale Resistant Voting Model** -- Our model shifts voting power away from token holders to hardware owners, where one validated router equals one vote. Additionally, Blockchain-based router tracking ensures that hoarding of devices are instantaneously detected by the network and ‘fake’ routers are locked out of the network. The liquidity incentive mechanism will be available to all users and not just people with routers so the entry barrier is removed in this case. +* Our model shifts voting power away from token holders to hardware owners, where one validated router equals one vote. Additionally, Blockchain-based router tracking ensures that hoarding of devices are instantaneously detected by the network and ‘fake’ routers are locked out of the network. The liquidity incentive mechanism will be available to all users and not just people with routers so the entry barrier is removed in this case. **Voting by Direct Democracy** -- Our voting mechanism would be classified as a Direct Democracy system. We are going to balance the voting power by only allowing token holders to have one router regardless of how many tokens they hold. We will make sure they got to go through SpiderConnect to gain more routers for their tokens if we agreed to that. Our DPI filters will monitor that keeping their identity anonymous. +* Our voting mechanism would be classified as a Direct Democracy system. We are going to balance the voting power by only allowing token holders to have one router regardless of how many tokens they hold. We will make sure they got to go through SpiderConnect to gain more routers for their tokens if we agreed to that. Our DPI filters will monitor that keeping their identity anonymous. - **How will spiderDAO try and prevent Whales/Bots from manipulating the Hardware Governnace?** - -- We are aware that whales/bots can buy more routers using new wallets to try and affect the governance model, but that will come at a heavy cost for adding more routers and also have to wait for a period of time deemed reasonable to the DAO. Users must have active transactions on the wallet before being able to vote to make sure bots and whales won't get access with ease. + **How will spiderDAO try and prevent Whales/Bots from manipulating the Hardware Governnace?** -- We will be keeping a log of every MAC Address and serial number for every router we add to our inventory, this we’ll be added to an on-chain ledger or on-chain database. This will help us to identify any clone or anyone trying to spoof/manipulate the hardware. +* We are aware that whales/bots can buy more routers using new wallets to try and affect the governance model, but that will come at a heavy cost for adding more routers and also have to wait for a period of time deemed reasonable to the DAO. Users must have active transactions on the wallet before being able to vote to make sure bots and whales won't get access with ease. + +* We will be keeping a log of every MAC Address and serial number for every router we add to our inventory, this we’ll be added to an on-chain ledger or on-chain database. This will help us to identify any clone or anyone trying to spoof/manipulate the hardware. We will also be in constant contact with the growing SpiderDAO community and the open-source community for beneficial ideas on how to make the governorate safer and more resilient to whales-resistance. -- If the essential data (explained below) is not matched to the end-user and they try to spoof or manipulate access. There will be 3 warnings followed by a ban from taking a part in our governance model for a limited time(still to be decided). The ban time will be increased systematically based on the number of times this is identified until the customer is banned indefinitely if the infringement persistently continues. - +* If the essential data (explained below) is not matched to the end-user and they try to spoof or manipulate access. There will be 3 warnings followed by a ban from taking a part in our governance model for a limited time(still to be decided). The ban time will be increased systematically based on the number of times this is identified until the customer is banned indefinitely if the infringement persistently continues. + **What is the essential data?** **The essential data is a combination of the following:** -- Encrypted wallet seed using aes-256-cbc encryption standard with an auto-generated passphrase* saved as part of the essential data. -- Router Mac Address to avoid it being cloned. -- Router serial number which cannot be cloned as it's a part of the chipset code. -- SHA-512 checksum for a temp file that is created with all the data above which is updated every time the router is rebooted with the timestamp. +* Encrypted wallet seed using aes-256-cbc encryption standard with an auto-generated passphrase* saved as part of the essential data. +* Router Mac Address to avoid it being cloned. +* Router serial number which cannot be cloned as it's a part of the chipset code. +* SHA-512 checksum for a temp file that is created with all the data above which is updated every time the router is rebooted with the timestamp. **PS:** Please note the passphrase would only be local and will be independent to the requests sent by the router for the governorate operations. **Is SpiderConnect Hardware Router open-source?** - -- Yes as we want to be involved much more in the open-source community, We are going to be using the Uboot environment with its open-source code to save the essential data which would be listed in the next question. -- To go into more detail on that point, We will also be giving our community members the option to choose between Open Source wireless drivers and the closed source ones for them to choose so we can make sure we offer an OpenSource friendly solution. +* Yes as we want to be involved much more in the open-source community, We are going to be using the Uboot environment with its open-source code to save the essential data which would be listed in the next question. + +* To go into more detail on that point, We will also be giving our community members the option to choose between Open Source wireless drivers and the closed source ones for them to choose so we can make sure we offer an OpenSource friendly solution. **PS:** No secured or closed source ROM will be needed using this solution - - **How we plan to build on Polkadot Ecosystem?** - -- We are planning to build using smart contracts at the beginning but as we scale up to more transactions, We are most likely to move toward a shared solution so we can cut the costs and take charge of how our blockchain will operate. -**How we plan to achieve on-chain and off-chain communication with SpiderConnect Routers and SpiderDAO governance?** + **How we plan to build on Polkadot Ecosystem?** -- We are planning to write a substrate faucet to communicate with our discord server for our customers to send the token needed for the vote, Initiate voting, pass on the vote for the voting process that would be operated through our discord server. -- Real votes will be done through our substrate faucet until the final Polkadot/SpiderDAO flavour features are fully-fledged. - +* We are planning to build using smart contracts at the beginning but as we scale up to more transactions, We are most likely to move toward a shared solution so we can cut the costs and take charge of how our blockchain will operate. +**How we plan to achieve on-chain and off-chain communication with SpiderConnect Routers and SpiderDAO governance?** +* We are planning to write a substrate faucet to communicate with our discord server for our customers to send the token needed for the vote, Initiate voting, pass on the vote for the voting process that would be operated through our discord server. +* Real votes will be done through our substrate faucet until the final Polkadot/SpiderDAO flavour features are fully-fledged. ## Team :busts_in_silhouette: ### Team members + * Nathan Varty (Full-Time, Founder, CEO) * Žiga Flis (Full-Time, Founder, Senior blockchain Developer & Analyst) * Anas Sayed (Full-Time, Founder, CTO, Development Manager, Architecture, Full Network Stack Implementation) @@ -116,40 +116,49 @@ We will also be in constant contact with the growing SpiderDAO community and the * Pierre Laurent (Strategic Advisor, Blockchain and crypto Enthusiast) ### Team Website + * https://spiderdao.io ### Legal Structure + **SpiderDAO** is incorporated in Cayman Island. ### Team's experience + **Nathan Varty** + * Experienced entrepreneur specialized in IoT development and operations, Skilled in management of onsite Developers. * Successfully overseeing SpiderVPN's operations since 2017. * Passionate about decentralizing global currency and governance with the vision to implement that in wider fields. * Over 5 years experience investing and trading in digital assets. **Žiga Flis** + * Worked as a Chief Technology Officer at RiveX, where he contributed to the development of various blockchain technologies. * Experienced in on and off-chain tech and has a passion for developing decentralized solutions. * Experienced in crypto markets since 2016. **Anas Sayed** + * Long standing Project Manager and working with teams of Developers and Administrators. * Worked on many projects in Entertainment/Telecommunications field including FuboTV, Pensil Media, SpiderVPN. * Currently working on different projects with market leaders in Telecommunications field. * Bachelor’s Degree in Computer Science from HICIT in Shorouk Academy, Egypt. **Alexy Petrunin** + * Experienced backend developers with full SDLC implementations. * Developed multiple OpenWRT projects. * Extensive knowledge in all Open Systems Interconnection (OSI) model. **Dr. Alfie Zhao** + * Chief Technology Officer, GL Technologies (Hong Kong) Limited. * Winner of CES innovation awards in 2019 and 2020. * PhD in engineering management with proven track record in hardware IoT since 2012. **Pierre Laurent** + * Co-founder at Atka advisory. * Overseeing the European operation of a cryptocurrency exchange as Blockchain Partnerships Manager in 2018 * Early adopter of Blockchain and advisor on several projects @@ -157,11 +166,13 @@ We will also be in constant contact with the growing SpiderDAO community and the * Tech-savvy, startup enthusiast, passionate about blockchain technologies. ### Team Code Repos + * https://github.com/spiderdao * https://github.com/painfull30 * https://github.com/flisko ### Team LinkedIn Profiles + * **Nathan Varty** https://www.linkedin.com/in/nathan-varty-b07235162/ * **Žiga Flis** https://www.linkedin.com/in/%C5%BEiga-flis-3112896b/ * **Anas Sayed** https://www.linkedin.com/in/anas-sayed-34a99b73/ @@ -169,10 +180,10 @@ We will also be in constant contact with the growing SpiderDAO community and the * **Dr. Alfie Zhao** https://www.linkedin.com/in/jianbin-zhao-2b04567/ * **Pierre Laurent** https://www.linkedin.com/in/pierrelaurent789/ - -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: ### Overview + * **Total Estimated Duration:** 2 Months/POC * **Full-time equivalent (FTE):** 15.57 * **Total Costs:** 1.67 BTC @@ -183,37 +194,43 @@ We will also be in constant contact with the growing SpiderDAO community and the | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | | 0b. | Documentation | We will provide both inline documentation of the code and a full tutorial that explains how to interact and communicate with the testnet protocol | -| 0c. | Testing Guide | The code will have proper unit-test coverage (>90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | +| 0c. | Testing Guide | The code will have proper unit-test coverage (>90%) to ensure functionality and robustness. In the guide we will describe how to run these tests | | 1. | Testing | We will conduct testing of the developed functionalities on Westend testnet. | | 2. | DAO framework | We are going to build our DAO framework using Ink! Smart Contracts for this milestone. | | 3. | Discord Communication | Write a substrate faucet to establish communication between SpiderConnect Hardware Router & discord server allowing contribution to SpiderDAO by allowing users to send the token needed for the vote, Initiate voting, pass on the vote for the voting process that would be operated through our discord server. | -| 4. | Build TestNet | The testnet will be based on Substrate framework for this milestone. | +| 4. | Build TestNet | The testnet will be based on Substrate framework for this milestone. | | 5. | Test SpiderDAO | Successfully connect DAO entities (individual voters) to Spider routers. This will include one use case to show the connection is established correctly using Discord communications. We will be using Python with the help of https://github.com/polkascan/py-substrate-interface library. | | 6. | Medium Article | Create a medium article to announce all deliveries to the community once passed evaluation. | | 7. | Repository | Repository including a README that describes the milestone and explains how to run, test and contribute | | 8. | Docker | A docker container that will also run on CI to test the deliverables of the milestone | ### Community engagement + We plan to write several pieces about SpiderDAO/SpiderVPN implementation. They include, but are not limited to: + * Weekly Medium Articles * Daily Twitter Threads and Posts * We also intend to engage community by running range of incentivised testnets to get more feedback from the existing end-users to improve our product. * Educating an Ideal processes of hardware voting policy in a DAO structure ## Future Plans + Future Developments will focus on the following: + * Incentive programs for validators * Bug bounties * Hackathon * Grants to develop new products under the SpiderDAO Umbrella -* Decentralized SpiderChat | SpiderCloud | SpiderMail +* Decentralized SpiderChat | SpiderCloud | SpiderMail **Open Source Development Opportunities** -* Hardware DAO Development + +* Hardware DAO Development * Networking Routers * Operating Systems -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: + Any additional information that you think is relevant to this application that hasn't already been included. * **What work has been done so far?** diff --git a/applications/Standard_Protocol.md b/applications/Standard_Protocol.md index 6ee0688ed9a..5965f7c8db1 100644 --- a/applications/Standard_Protocol.md +++ b/applications/Standard_Protocol.md @@ -1,7 +1,6 @@ # Standard Protocol - -## Project Overview :page_facing_up: +## Project Overview :page_facing_up: ### Overview @@ -10,12 +9,15 @@ Standard Protocol is a collaterized algorithmic stablecoin protocol for syntheti ### Problems of current algorithmic stablecoins #### 1. Too much focus on price stability, no sustainable use case for interoperability + Current algorithmic stablecoins focus only on automated price stability. Although they provide some interoperability between tokens with initial distribution in yield farming, but currently there is no sustainable way for them to interoperate with financial activities without the reward. Also, other algorithmic stablecoins which uses incentives in cases regarding circulating supply(e.g. contractionary, expansionary cases) are not showing sustainability to preserve 1 dollar peg. -#### 2. Oracles are centralized, and there is no decentralized ecosystem to reward them +#### 2. Oracles are centralized, and there is no decentralized ecosystem to reward them + One can be dependant to dexes, but they are prone to flash loans, making arbitrage data compared to centralized exchange. In order to provide aggregated and balanced data, oracle providers must be rewarded. -#### 3. Auctions are hard to track and centralized +#### 3. Auctions are hard to track and centralized + Auctions after liquidation are hard to track and participate, leaving only hardcore traders to take advantage of arbitrage. More decentralized way to provide liquidation must be considered. Auction orders come in high volume of collateral, and this can lead to plutocracy. ### Solutions @@ -40,7 +42,7 @@ Instead of hosting an auction for liquidating collaterals, Standard protocol dep #### token regisrty `/token` -Token manages asset that flows in and out with xcmp in polkadot ecosystem. assets are managed with unique identifier. +Token manages asset that flows in and out with xcmp in polkadot ecosystem. assets are managed with unique identifier. #### oracle reward module `/oracle` @@ -53,9 +55,9 @@ Market module in standard protocol manages pair for automated market maker(AMM) #### vault module `/vault` -Vault module in standard protocol is a collateral debt position engine where +Vault module in standard protocol is a collateral debt position engine where -### Ecosystem Fit +### Ecosystem Fit Standard protocol will act as the catalyst for other parachain's financial activities for enabling leverage trading and Arbitrage in AMM created from liquidation. It will also open a protocol for synthetic asset market with decentralized oracle ecosystem. @@ -66,19 +68,22 @@ Standard protocol will act as the catalyst for other parachain's financial activ Hyungsuk Kang, team leader ### Legal Structure + Standard protocol is being made with Apache 2.0 license. Legal entity is being built in Singapore right now. ### Team's experience -Hyungsuk is Plasm network's core developer. He developed Subswap, AMM in substrate, and he wants to extend it to make the next finance in Polkadot ecosytem using XCM module and collateral debt position. He is also kernel and tendermint fellow. + +Hyungsuk is Plasm network's core developer. He developed Subswap, AMM in substrate, and he wants to extend it to make the next finance in Polkadot ecosytem using XCM module and collateral debt position. He is also kernel and tendermint fellow. ### Team Code Repos -* https://github.com/digitalnativeinc/standard-substrate +* https://github.com/digitalnativeinc/standard-substrate ### Team LinkedIn Profiles + * https://www.linkedin.com/in/hyungsukkang -## Development Roadmap :nut_and_bolt: +## Development Roadmap :nut_and_bolt: ### Overview @@ -92,6 +97,7 @@ To reward the network participant, Standard protocol proposes new PoS reward sys * **Status:** [Terminated](https://github.com/w3f/Grants-Program/pull/244#issuecomment-1014764739) ### Milestone 1 - Middleware for data submission and runtime integration + * **Estimated Duration:** 1 month * **FTE:** 1 * **Costs:** 500DAI @@ -100,7 +106,7 @@ This milestone focuses on building a oracle provider client middleware which sub ### Oracle provider client -As chainlink and other oracle solution has a middleware or submitting client from off-chain, Standard also has its oracle client. Oracle provider client is actually a bot that uses [polkadot-js api](https://github.com/scs/substrate-api-client/blob/master/tutorials/api-client-tutorial/src/main.rs) to submit information in oracle module in a certain periods(e.g. 2 hour, 4 hour). For example, to send an oracle xt from an oracle client, +As chainlink and other oracle solution has a middleware or submitting client from off-chain, Standard also has its oracle client. Oracle provider client is actually a bot that uses [polkadot-js api](https://github.com/scs/substrate-api-client/blob/master/tutorials/api-client-tutorial/src/main.rs) to submit information in oracle module in a certain periods(e.g. 2 hour, 4 hour). For example, to send an oracle xt from an oracle client, ```javascript= // Loads config @@ -149,32 +155,29 @@ Here is the overall workflow for the client operation, and add-ons and options a ## Unit tests -Standard protocol applies test driven development(TDD) on building runtime modules for the grant. +Standard protocol applies test driven development(TDD) on building runtime modules for the grant. Here are unit tests that will be done along the development in the runtime module. ## Oracle oracle in milestone 1 should achieve: -- Only Root account can register oracle providers for slots to submit off-chain data -- If slots are not open for an entity in the storage, a new oracle provider initializes the slot with the oracle provider count. -- When the provider is designated for a slot, it can only submit data for a designated slot -- If one reports slashing for the slot, runtime validates the slot data with iqr rule and remove provider and set the value as zero if the value violates it. -- zero values are excluded and the median is calculated in both even and odd cases +* Only Root account can register oracle providers for slots to submit off-chain data +* If slots are not open for an entity in the storage, a new oracle provider initializes the slot with the oracle provider count. +* When the provider is designated for a slot, it can only submit data for a designated slot +* If one reports slashing for the slot, runtime validates the slot data with iqr rule and remove provider and set the value as zero if the value violates it. +* zero values are excluded and the median is calculated in both even and odd cases To check this, oracle provider module should have these test functions: -- `add_oracle_provider_works`: Oracle should be added by the root account for now until the module includes session callback between `pallet-staking` and `pallet-session` as a impl of `SessionManager`. -- `oracle_report_works`: Oracle provider should only be able to submit data only in designated slot, and create new batch if the price data has not been reported yet. -- `oracle_slash_works`: when one reports slashing for oracle provider in a slot, the runtime should run iqr rule to find out whether the slot value violates the rule from the collected oracle data batch. -- `oracle_excludes_zeros_and_return_median`: Oracle runtime should exclude zero-values since it means the data is empty or not available due to violation. median should be returned from the remainder of filtered batch. -- `oracle_excludes_zeros_and_return_median_even`: the purpose is also same with the previous test function, but the batch length is even. - - - +* `add_oracle_provider_works`: Oracle should be added by the root account for now until the module includes session callback between `pallet-staking` and `pallet-session` as a impl of `SessionManager`. +* `oracle_report_works`: Oracle provider should only be able to submit data only in designated slot, and create new batch if the price data has not been reported yet. +* `oracle_slash_works`: when one reports slashing for oracle provider in a slot, the runtime should run iqr rule to find out whether the slot value violates the rule from the collected oracle data batch. +* `oracle_excludes_zeros_and_return_median`: Oracle runtime should exclude zero-values since it means the data is empty or not available due to violation. median should be returned from the remainder of filtered batch. +* `oracle_excludes_zeros_and_return_median_even`: the purpose is also same with the previous test function, but the batch length is even. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0| -| 0b. | Documentation | Documentation will introduce how to install the oracle and participate to get block reward | +| 0b. | Documentation | Documentation will introduce how to install the oracle and participate to get block reward | | 1. | Oracle client | Oracle client to receive information from external sources then submit information regularly to substrate runtime | | 2. | Modified Oracle module | Oracle module to register operators and batch | | 3. | Unit test codes | Unit test codes in `tests.rs` in each runtime module | @@ -182,13 +185,14 @@ To check this, oracle provider module should have these test functions: | 5. | Dockerfile | Dockerfile for running Standard protocol binary will be provided | ### Milestone 2 - PoS oracle reward distribution + * **Estimated Duration:** 1 month * **FTE:** 1 * **Costs:** 500DAI -This milestone focuses on including session callbacks related to sessions in implementations of `SessionManager` trait in `pallet-staking` module, and all related module will be tested with its separate implementation of `SessionManager` connected to `pallet-session` in a mock environment. +This milestone focuses on including session callbacks related to sessions in implementations of `SessionManager` trait in `pallet-staking` module, and all related module will be tested with its separate implementation of `SessionManager` connected to `pallet-session` in a mock environment. -## Vault +## Vault Vault in milestone 2 should have a trait for dependency Injection: @@ -217,209 +221,204 @@ where the it will be included in `pallet-staking` module's `SessionManager` trai /// Once the first new_session is planned, all session must start and then end in order, though /// some session can lag in between the newest session planned and the latest session started. impl pallet_session::SessionManager for Module { - fn new_session(new_index: SessionIndex) -> Option> { - frame_support::debug::native::trace!( - target: LOG_TARGET, - "[{}] planning new_session({})", - >::block_number(), - new_index - ); - Self::new_session(new_index) - } - fn start_session(start_index: SessionIndex) { - frame_support::debug::native::trace!( - target: LOG_TARGET, - "[{}] starting start_session({})", - >::block_number(), - start_index - ); - Self::start_session(start_index) - } - fn end_session(end_index: SessionIndex) { - frame_support::debug::native::trace!( - target: LOG_TARGET, - "[{}] ending end_session({}) with rebase", - >::block_number(), - end_index - ); + fn new_session(new_index: SessionIndex) -> Option> { + frame_support::debug::native::trace!( + target: LOG_TARGET, + "[{}] planning new_session({})", + >::block_number(), + new_index + ); + Self::new_session(new_index) + } + fn start_session(start_index: SessionIndex) { + frame_support::debug::native::trace!( + target: LOG_TARGET, + "[{}] starting start_session({})", + >::block_number(), + start_index + ); + Self::start_session(start_index) + } + fn end_session(end_index: SessionIndex) { + frame_support::debug::native::trace!( + target: LOG_TARGET, + "[{}] ending end_session({}) with rebase", + >::block_number(), + end_index + ); T::Rebase::rebase(); - Self::end_session(end_index) - } + Self::end_session(end_index) + } } ``` - vault in milestone 2 should achieve: -- In each era, vault module should bring registered stablecoin price from oracle module with its asset id (1) and rebase its total supply to `(circulating supply) / (oracle price)` in order to satisfy the ratio `(circulating supply) : (oracle price) = (total supply) : (1.0(USD) in decimal configured in the substrate chain)`. -- Vault module should burn or mint stablecoin's module account's balance according to rebased balance -- Alert community when total supply cannot be decreased anymore to keep the ratio(in case where decreased total supply exceeds circulating supply) in order to propose emergency shutdown or take further actions(e.g. issuing bonds, using community vault from stability fee to stabilize the ratio) +* In each era, vault module should bring registered stablecoin price from oracle module with its asset id (1) and rebase its total supply to `(circulating supply) / (oracle price)` in order to satisfy the ratio `(circulating supply) : (oracle price) = (total supply) : (1.0(USD) in decimal configured in the substrate chain)`. +* Vault module should burn or mint stablecoin's module account's balance according to rebased balance +* Alert community when total supply cannot be decreased anymore to keep the ratio(in case where decreased total supply exceeds circulating supply) in order to propose emergency shutdown or take further actions(e.g. issuing bonds, using community vault from stability fee to stabilize the ratio) To check this, vault module should have these test functions: -- `supply_is_rebased_in_each_era`: Using an oracle module, set an oracle price and start an era so that the vault module can executes rebase mechanism. The total supply of the stablecoin is checked whether it changed to the right amount. -- `report_emergency`: check whether vault module reports when the rebased next total supply is less than the circulating supply. - +* `supply_is_rebased_in_each_era`: Using an oracle module, set an oracle price and start an era so that the vault module can executes rebase mechanism. The total supply of the stablecoin is checked whether it changed to the right amount. +* `report_emergency`: check whether vault module reports when the rebased next total supply is less than the circulating supply. ## Oracle oracle will replicate the `pallet-staking` module regarding election of the oracle provider and the reward logic. However, there will be difference in how the elected provider(or validator) is allocated to the slot. The module only accepts the stash account to submit oracle data once `validate()` tx has been finalized. -For example, there will be addition in the `select_and_update_validators` function code +For example, there will be addition in the `select_and_update_validators` function code ```rust= /// Select the new validator set at the end of the era. - /// - /// Runs [`try_do_phragmen`] and updates the following storage items: - /// - [`EraElectionStatus`]: with `None`. - /// - [`ErasStakers`]: with the new staker set. - /// - [`ErasStakersClipped`]. - /// - [`ErasValidatorPrefs`]. - /// - [`ErasTotalStake`]: with the new total stake. - /// - [`SnapshotValidators`] and [`SnapshotNominators`] are both removed. - /// - /// Internally, [`QueuedElected`], snapshots and [`QueuedScore`] are also consumed. - /// - /// If the election has been successful, It passes the new set upwards. - /// - /// This should only be called at the end of an era. - fn select_and_update_validators(current_era: EraIndex) -> Option> { - if let Some(ElectionResult::> { - elected_stashes, - exposures, - compute, - }) = Self::try_do_election() { - // Totally close the election round and data. - Self::close_election_window(); - - // Populate Stakers and write slot stake. - let mut total_stake: BalanceOf = Zero::zero(); - exposures.into_iter().for_each(|(stash, exposure)| { - total_stake = total_stake.saturating_add(exposure.total); - >::insert(current_era, &stash, &exposure); - - let mut exposure_clipped = exposure; - let clipped_max_len = T::MaxNominatorRewardedPerValidator::get() as usize; - if exposure_clipped.others.len() > clipped_max_len { - exposure_clipped.others.sort_by(|a, b| a.value.cmp(&b.value).reverse()); - exposure_clipped.others.truncate(clipped_max_len); - } - >::insert(¤t_era, &stash, exposure_clipped); - }); - - // Insert current era staking information - >::insert(¤t_era, total_stake); - - // collect the pref of all winners - for (i, stash) in elected_stashes.iter().enumerate() { + /// + /// Runs [`try_do_phragmen`] and updates the following storage items: + /// - [`EraElectionStatus`]: with `None`. + /// - [`ErasStakers`]: with the new staker set. + /// - [`ErasStakersClipped`]. + /// - [`ErasValidatorPrefs`]. + /// - [`ErasTotalStake`]: with the new total stake. + /// - [`SnapshotValidators`] and [`SnapshotNominators`] are both removed. + /// + /// Internally, [`QueuedElected`], snapshots and [`QueuedScore`] are also consumed. + /// + /// If the election has been successful, It passes the new set upwards. + /// + /// This should only be called at the end of an era. + fn select_and_update_validators(current_era: EraIndex) -> Option> { + if let Some(ElectionResult::> { + elected_stashes, + exposures, + compute, + }) = Self::try_do_election() { + // Totally close the election round and data. + Self::close_election_window(); + + // Populate Stakers and write slot stake. + let mut total_stake: BalanceOf = Zero::zero(); + exposures.into_iter().for_each(|(stash, exposure)| { + total_stake = total_stake.saturating_add(exposure.total); + >::insert(current_era, &stash, &exposure); + + let mut exposure_clipped = exposure; + let clipped_max_len = T::MaxNominatorRewardedPerValidator::get() as usize; + if exposure_clipped.others.len() > clipped_max_len { + exposure_clipped.others.sort_by(|a, b| a.value.cmp(&b.value).reverse()); + exposure_clipped.others.truncate(clipped_max_len); + } + >::insert(¤t_era, &stash, exposure_clipped); + }); + + // Insert current era staking information + >::insert(¤t_era, total_stake); + + // collect the pref of all winners + for (i, stash) in elected_stashes.iter().enumerate() { >::insert(i, stash.clone()); // allocating slots for elected oracle provider - let pref = Self::validators(stash); - >::insert(¤t_era, stash, pref); - } + let pref = Self::validators(stash); + >::insert(¤t_era, stash, pref); + } - // emit event - Self::deposit_event(RawEvent::StakingElection(compute)); - - log!( - info, - "💸 new validator set of size {:?} has been elected via {:?} for era {:?}", - elected_stashes.len(), - compute, - current_era, - ); - - Some(elected_stashes) - } else { - None - } - } + // emit event + Self::deposit_event(RawEvent::StakingElection(compute)); + + log!( + info, + "💸 new validator set of size {:?} has been elected via {:?} for era {:?}", + elected_stashes.len(), + compute, + current_era, + ); + + Some(elected_stashes) + } else { + None + } + } ``` Also, slash module function should include verifier from milestone 1. ```rust= /// Slash the validator for a given amount of balance. This can grow the value - /// of the slash in the case that the validator has less than `minimum_balance` - /// active funds. Returns the amount of funds actually slashed. - /// - /// Slashes from `active` funds first, and then `unlocking`, starting with the - /// chunks that are closest to unlocking. - fn slash( - &mut self, - mut value: Balance, - minimum_balance: Balance, + /// of the slash in the case that the validator has less than `minimum_balance` + /// active funds. Returns the amount of funds actually slashed. + /// + /// Slashes from `active` funds first, and then `unlocking`, starting with the + /// chunks that are closest to unlocking. + fn slash( + &mut self, + mut value: Balance, + minimum_balance: Balance, slot: SlotIndex, - ) -> Balance { - let batch = Prices::get(_id).unwrap(); - let value = batch[_slot as usize]; - let det = Self::determine_outlier(batch, value); - ensure!(det, Error::::NotOutlier); - let pre_total = self.total; - let total = &mut self.total; - let active = &mut self.active; - - let slash_out_of = | - total_remaining: &mut Balance, - target: &mut Balance, - value: &mut Balance, - | { - let mut slash_from_target = (*value).min(*target); - - if !slash_from_target.is_zero() { - *target -= slash_from_target; - - // don't leave a dust balance in the staking system. - if *target <= minimum_balance { - slash_from_target += *target; - *value += sp_std::mem::replace(target, Zero::zero()); - } - - *total_remaining = total_remaining.saturating_sub(slash_from_target); - *value -= slash_from_target; - } - }; - - slash_out_of(total, active, &mut value); - - let i = self.unlocking.iter_mut() - .map(|chunk| { - slash_out_of(total, &mut chunk.value, &mut value); - chunk.value - }) - .take_while(|value| value.is_zero()) // take all fully-consumed chunks out. - .count(); - - // kill all drained chunks. - let _ = self.unlocking.drain(..i); - - pre_total.saturating_sub(*total) - } + ) -> Balance { + let batch = Prices::get(_id).unwrap(); + let value = batch[_slot as usize]; + let det = Self::determine_outlier(batch, value); + ensure!(det, Error::::NotOutlier); + let pre_total = self.total; + let total = &mut self.total; + let active = &mut self.active; + + let slash_out_of = | + total_remaining: &mut Balance, + target: &mut Balance, + value: &mut Balance, + | { + let mut slash_from_target = (*value).min(*target); + + if !slash_from_target.is_zero() { + *target -= slash_from_target; + + // don't leave a dust balance in the staking system. + if *target <= minimum_balance { + slash_from_target += *target; + *value += sp_std::mem::replace(target, Zero::zero()); + } + + *total_remaining = total_remaining.saturating_sub(slash_from_target); + *value -= slash_from_target; + } + }; + + slash_out_of(total, active, &mut value); + + let i = self.unlocking.iter_mut() + .map(|chunk| { + slash_out_of(total, &mut chunk.value, &mut value); + chunk.value + }) + .take_while(|value| value.is_zero()) // take all fully-consumed chunks out. + .count(); + + // kill all drained chunks. + let _ = self.unlocking.drain(..i); + + pre_total.saturating_sub(*total) + } } ``` -# Unit test - -Unit tests are all identical with the staking module's test in that all logics are identical regarding slash, reward and validation. - +# Unit test +Unit tests are all identical with the staking module's test in that all logics are identical regarding slash, reward and validation. | Number | Deliverable | Specification | | ------------- | ------------- | ------------- | | 0a. | License | Apache 2.0 | -| 0c. | Documentation | Documentation will introduce how to nominate | -| 1. | Vault module | Vault module will declare dependancy injection trait to use session callback in `pallet-staking` module and the test code with separate `SessionManager` implementation will be provided | -| 2. | Modified Staking module | `pallet_staking` module which has two config trait for rebase callback and oracle staking callback will be provided | -| 3. | Oracle module | same as staking module including curve integration but difference in slot allocation and separate slashing verifier will be included | +| 0c. | Documentation | Documentation will introduce how to nominate | +| 1. | Vault module | Vault module will declare dependancy injection trait to use session callback in `pallet-staking` module and the test code with separate `SessionManager` implementation will be provided | +| 2. | Modified Staking module | `pallet_staking` module which has two config trait for rebase callback and oracle staking callback will be provided | +| 3. | Oracle module | same as staking module including curve integration but difference in slot allocation and separate slashing verifier will be included | | 4. | Unit test code | Unit test codes in `tests.rs` in each runtime module with separate `SessionManager` implementation | | 5. | Docker | We will provide a dockerfile to demonstrate the full functionality of Standard protocol chain | - - ## Future Plans + - Add more prices to add from the oracle (e.g. stock prices, commodities, etc) provider -- Full function test on Kusama/Rococo. -- Full function test on Polkadot. +* Full function test on Kusama/Rococo. +* Full function test on Polkadot. -## Additional Information :heavy_plus_sign: +## Additional Information :heavy_plus_sign: -- Pitch: [https://whitepaper.standardprotocol.org](https://whitepaper.standardprotocol.org) +* Pitch: [https://whitepaper.standardprotocol.org](https://whitepaper.standardprotocol.org) diff --git a/applications/Starry_Network.md b/applications/Starry_Network.md index e44ac7b822b..d54cee82bbe 100644 --- a/applications/Starry_Network.md +++ b/applications/Starry_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# Starry Protocol -* **Project Name:** Starry Protocol * **Proposer:** [Starry Network](https://github.com/Starry-Network) * **Payment Address:** 0xe29DE8c6088d241647e6456F8b4755a3D0f7c8B1 diff --git a/applications/StorageHub.md b/applications/StorageHub.md new file mode 100644 index 00000000000..ac54a8ebfc4 --- /dev/null +++ b/applications/StorageHub.md @@ -0,0 +1,169 @@ +# StorageHub Grant Application + +- **Team Name:** Moonsong Labs +- **Payment Address:** USD Wire Preferred +- **[Level](https://github.com/w3f/Grants-Program/tree/master#level_slider-levels):** 3 + +## Project Overview :page_facing_up: + +### Overview + +* Tagline Describer + * StorageHub is a decentralized storage public good parachain optimized for file based storage and larger data sets that are not suitable to be stored directly in standard parachain storage. The proposed parachain will provide developers in the Polkadot ecosystem with an alternate decentralized and substrate-based storage solution and functionality. + +* Purpose + * The goal of this project is to provide storage for web3 applications and protocols within the Polkadot & Kusama ecosystems. Unlike other storage protocols that focus on end user or enterprise storage scenarios, StorageHub’s feature set optimizes for web3 application storage use cases. StorageHub aims to provide a decentralized storage option that allows web3 applications to store large files and large data sets in a cost efficient way without sacrificing decentralization properties. + +* Problem + * Storage oriented chains, like Filecoin and Arweave, have emerged to provide more efficient and decentralized storage capabilities. However, these chains are standalone chains, and are not designed to interoperate with other chains. The problem is that web3 apps need smart contract logic and compute to be combined with storage to make a complete solution, but smart contracts and compute generally reside on different chains (e.g. Ethereum Mainnet, L2 rollups, Parachains) vs. on the storage optimized chains (Filecoin, Arweave). In response, these storage chains have tried to bolster their smart contract capabilities (e.g. Filecoin’s FVM, Arweave’s Smartweave), but they have and will continue to be hard pressed to convince all compute and smart contract activity to migrate to their chains. + + * The ideal scenario would be to combine smart contract execution from e.g. a Substrate based Polkadot parachain such as Moonbeam or Astar with storage from a storage optimized chain like Arweave. If we look at NFT scenarios as an example, this is happening. The scenario is that you have an NFT contract on Mainnet, that has a pointer to a JPEG via an Arweave URL. The problem is that this is a one-way pointer between 2 independent systems. It is up to the application to mediate interactions between the 2 chains in the client. There is no awareness or connection between the contract and the JPEG other than the URL pointer in the contract. What if the contract could update access to and ownership of the actual data itself? What if the contract could read and act on the data stored? Simple functionality like this would open up a large number of new scenarios. End user UX could be substantially improved by removing the need for the user to understand and interact directly with both the contract and the storage blockchains, using potentially different accounts, keys, etc. + +* Vision + * StorageHub is a storage optimized parachain that is designed to work with other Polkadot & Kusama parachains. It focuses on storing data in an efficient and decentralized way, while allowing that storage to be accessed, used, and managed by other parachains. It will be possible for users to directly interact with the storage on the chain, but StorageHub also seeks to natively interoperate with existing parachains via XCM. + +* Inspiration + * Amazon S3 + * (https://en.wikipedia.org/wiki/Amazon_S3) was a key building block of web2 cloud infrastructure that greatly eased and improved data storage in web2 applications. With S3 devs could store arbitrarily large amounts of data in their apps without needing to get bogged down with storage infrastructure or scaling concerns. StorageHub seeks to do something similar for web3 devs building on Polkadot. + + * Filecoin + * (https://filecoin.io/) is a storage optimized chain that creates a 2 sided marketplace of storage providers and storage consumers. The project is responsible for key innovations such as ipfs and libp2p, among other things. In many ways filecoin sets the standard for decentralized storage in the web3 space. Although the protocol seems focused on trying to compete with cloud and other centralized storage providers. + + * Arweave + * (https://www.arweave.org/) is a storage optimized chain like filecoin, but that emphasizes permanent storage vs creating a time based storage marketplace. Users pay once to store data on arweave forever. It is popular to use for metadata associated with NFTs, among other things. + + * Project Greenfield + * (https://github.com/bnb-chain/greenfield-whitepaper/blob/main/README.md) is a storage optimized chain designed to work with the BNB chain. It was born out of practical needs that the state of BNB chain is already many terabytes large and there is a need to offload unnecessary storage from the main BNB chain. There are lots of good cross chain ideas in Greenfield including having storage on Greenfield represented as NFTs on BNB chain which can be managed and whose ownership can be changed. + +### Project Details + +* Design and Implementation Principles + * StorageHub will be a Substrate-native implementation deployed to both Kusama and Polkadot. + * It will be a public good chain that uses DOT for fees, governance, and other utilities. + * It will offer native XCM support such that parachains can interact with stored data and metadata in a trustless way.. + * End users and Dapps should be able to store and retrieve stored data from the chain. + * The chain will create a 2 sided marketplace of storage providers and storage consumers. + * A minimum of N copies of any given piece of data should be stored such that the system can survive the loss of some copies without losing the original dataset. Erasure encoding or similar technique could be optionally used to achieve this. + * On the tradeoff spectrum between decentralization vs performance, we opt to always maintain good decentralization properties even if that means less performance is possible. + * There will need to be a network of storage providers that supply storage to the blockchain. + * The parachain will track metadata about the data being stored, and facilitate payments between the data owner and the storage provider. + * A set of metadata associated with any stored data will be managed by StorageHub. This will allow the data owner to control access, and to transfer ownership of the data to other parties. + * StorageHub doesn’t aim to have smart contract functionality itself. Rather it strives to integrate, work with, and complement other smart contract or native parachains. + * In creating the design for StorageHub, we will leverage previous research into polkadot and substrate based filestorage solutions such as: + * https://github.com/w3f/Grants-Program/pull/1888 + * https://github.com/common-good-storage/report/blob/master/src/first.md + +* Key Questions and Anticipated Challenges + * Existing storage networks focus more on storage but less on user accessibility to that data. But storage without accessibility isn’t that useful to users. Can we incorporate outside accessibility guarantees into the protocol? + * What type of storage will it provide? Only immutable hash/value type or will it support mutable references (like a filesystem, useful to store/manage a web service or page) + * What kind of XCM interaction (API) do we want to support? + * XCM (mostly HRMP) costs may make some scenarios prohibitive. + * Given the costs of XCM, to what degree does it make sense to store metadata on StorageHub vs on the controlling chain? + * What do sustainable economics look like for storage providers, especially given that a public good chain won’t have a token to help bootstrap this side of the market? + * How is data provided and stored without increasing PoV? This will most likely need to be a combination of offchain workers and a separate storage system. Regular substrate state can’t be used for larger data storage, it would be used to keep tracking information about where and what data is stored. + * What does this new data provider node look like and how does it work with other node types supporting the system? + * How will the system ensure that enough copies of a given piece of data are present and available, given that storage provider nodes can go offline at any time. + * How is it checked that data providers have the data they are being paid to store? What are the consequences of failing this check? + * How do you manage censorship of data? + * Different kinds of data that could be subject to take down requests. Data that e.g. a political party doesn’t like. Data that is illegal in a given jurisdiction due to copyright or similar. Data that is both illegal and morally offensive. + * Perhaps OpenGov tracks could be used for censorship takedowns. + * Or data storage providers could be given censorship controls, and a permissionless staking design would make it so token holders could vote out providers that are out of line with community censorship standards. + + +### Ecosystem Fit +* Where and How Does StorageHub Fit In + * There are currently no native Polkadot decentralized storage solutions and StorageHub aims to fill that gap. + * Crust provides an incentive layer on top of existing storage protocols like ipfs. Whereas StorageHub seeks to be a storage provider itself. + * StorageHub will be natively accessible by other parachains via XCM. + +* Target Audience + * StorageHub is targeted for chains, contracts, teams and individuals that require data storage of larger datasets, and who value that storage being decentralized, censorship resistant, and permanent as long as storage fees are paid. + * StorageHub will prioritize web3 developers that want to incorporate decentralized storage into their applications. This means a focus on APIs, SDKs, developer docs and education. + * StorageHub will secondarily provide a reference application which allows users to directly interact with the system, storing data and managing data storage. + +* Use Cases + * NFT, NFT marketplace, and Metaverse metadata storage + * Dapps that require data storage + * Personal and enterprise data storage - same as other storage chains. + * DAO owned data assets - DAOs operating on existing parachains can manage access to and ownership of data assets on StorageHub. + * “True” NFTs that can have the entirety of their associated data assets on-chain via a combination of an e.g. NFT contract and StorageHub stored assets. + * Markets for data sets using NFT marketplaces. + * New types of smart contracts that can act on StorageHub stored data on an one off or continuous basis + + +## Team :busts_in_silhouette: + +### Team members +* Team Leader: Derek Yoo +* Team: + * Alan Sapède + * Chase Williams + * Olivia Smith + * Engineers to be hired + +### Contact + +- **Contact Name:** Chase Williams +- **Contact Email:** Chase@moonsonglabs.com +- **Website:** https://moonsonglabs.com/ + +### Legal Structure + +- **Registered Address:** 1500 District Ave Burlington, MA 01803 +- **Registered Legal Entity:** Delaware C Corp + +### Team's experience + +* The Moonsong Labs protocol engineering team has deep expertise in Substrate, EVM, cross chain technologies, and launching parachains on Kusama and Polkadot. Our team is the core engineering team for the Moonbeam Network and have made significant contributions to the ecosystem, such as contributions to Frontier, the Moonwall testing framework, parachain-staking pallet, and xcm tools. The engineering team is made up of 13+ engineers and is rapidly growing.  + +* Team Example Code Repos: + * https://github.com/Moonsong-Labs + * https://github.com/moonbeam-foundation/moonbeam + +* Team LinkedIn Profiles: + * [Alan Sapede](https://www.linkedin.com/in/alansapede/) + * [Derek Yoo](https://www.linkedin.com/in/derek-yoo-8a050/) + * [Olivia Smith](https://www.linkedin.com/in/olivia-smith-69966616a/) + * [Chase Williams](https://www.linkedin.com/in/chase-williams-442712b1/) + * Engineering Team TBD + +## Development Roadmap :nut_and_bolt: + +### Overview +* Total Estimated Duration: 2 Months + * Milestone #1: 1 Month + * Milestone #2: 1 Month +* Full-Time Equivalent (FTE): 2.5 +* Total Costs: $84,500 (USD) + +### Milestone #1: Research & Design +* Estimated duration: 1 Month +* FTE: 2.5 +* Costs: $42,250 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | Copyright and Licenses | CC BY 4.0 / GPLv3 | +| **0b.** | Research & Investigation | * Understand and clarify key requirements via conversations with key stakeholders
          * Study existing solutions and designs to see what technologies and approaches can be leveraged vs. being created
          * Research decentralized storage competitive projects, including but not limited to Filecoin, Arweave, Sia, Storj as well as existing storage work in the Polkadot ecosystem
          * Examine trade offs other decentralized storage providers have made including, but not limited to retrieval times, small v. large files, resiliency, cost efficacy, security & privacy, redundancy, user learning curve and environmental sustainability
          * Begin to design features compatible with Polkadot’s technical approach and philosophy
          * The research & design document will include the gathered requirements and the list of researched solutions & features that could meet those requirements, as well as all supporting evidence and documentation that led to those proposed requirements and features. The document will also expand its research on the “Key Questions and Anticipated Challenges” section | +| **0c.** | Feature Analysis | * In depth research of the technical feasibility of key features and components
          *Evaluation of proposed feature sets, inclusive of a detailed compatibility/tradeoff matrix leading to a clearly defined set of proposed StorageHub features
          * Stakeholders will be asked to provide feedback on those compatibility/tradeoffs and to help choose a good combination of features
          * Definition and documentation of key use cases and scenarios | +| **0d.** | Article | * The main deliverable for the first month is v0.5 of the research & design document. The research and design document will include the feature analysis, proposed MVP feature set including key use cases, and address the points in (0b.) and (0c.) | + +### Milestone #2: Technical Deliverables +* Estimated Duration: 1 month +* FTE: 2.5 +* Costs: $42,250 (USD) + +| Number | Deliverable | Specification | +| -----: | ----------- | ------------- | +| **0a.** | License Type | CC BY 4.0 / GPLv3 | +| **0b.** | Documentation | * For the second milestone we will provide v1.0 of the research & design document. The v1.0 document will include a high level technical design & architecture of StorageHub, including major subsystems, incorporating and building upon research from the first v0.5 milestone
          * This v1.0 research and design document will be shared with key stakeholders to obtain specific feedback that will help us continue to refine StorageHub
          * In addition to this, we will also begin to build prototype code that supports and tests the v1.0 technical design considerations. A basic tutorial will be included that explains how a user can run our prototype code and send test transactions | +| **0c.** | Testing & Testing Guide | * Software developed for this milestone will be prototype quality, and thus will not have the tests required for production deployment. However, the prototype code will be sufficient to demonstrate viability or compatibility of key aspects of the design approach
          * As outlined in (0b.), a basic tutorial will be included that explains how a user can run our prototype code and send test transactions | +| **0d.** | Docker | * We will provide a Dockerfile(s) that can be used to run the prototype associated with this milestone | +| **0e.** | Prototype Code | * We will create a Substrate and or RUST prototype to validate proposed designs described in the v1.0 design doc. In particular, the approach for the data provider role, and being able to store data in a redundant fashion, and retrieve data from the provider
          * The source code for the prototype will be delivered as part of the second month milestone. The prototype will have limited features (e.g. not decentralized, limited API, etc) or might not be complete but will provide sufficient functionalities to demonstrate key parts of the proposed design
          * We will provide a Dockerfile(s) that can be used to run the prototype associated with this milestone | +| **0f.** | Resource Estimation & Planning | * Estimate the time, budget, and resources required to implement a minimum viable feature set for the project
          * Break down the feature into smaller tasks or user stories
          * Create a proposed project plan that includes implementation milestones, and responsibilities
          * Include proposed next steps in the research and design doc | +| **0g.** | Article | * The main deliverables for this milestone are defined as below
          * Progressing the v0.5 document to a v1.0 state outlined in section (0b.)
          * A Substrate and or RUST prototype to validate proposed designs described in the v1.0, outlined in section (0e.)
          * A basic tutorial will be included that explains how a user can run our prototype code and send test transactions outlined in section (0c.) | + + +## Future Plans +* We are currently in the process of hiring fulltime resources that will be dedicated to this engineering effort. +* The intended long term plan is to successfully complete this initial grant to then set us up to apply for a follow on long term grant diff --git a/applications/Stylograph.md b/applications/Stylograph.md new file mode 100644 index 00000000000..1d9f7c52261 --- /dev/null +++ b/applications/Stylograph.md @@ -0,0 +1,206 @@ + +# Pallet Stylograph + +- **Team Name:** GenesisDAO by Deep Ink Ventures GmbH +- **Payment Address:** Ethereum Mainnet, 0x918a4363C35156c8F85F86795a79189e5A1ef557, USDC +- **Level:** 3 + +## Overview + +> **Stylograph** [ stahy-luh-graf, -grahf ] +> +> *A writing instrument for applying ink to paper.* + + +Stylograph is a framework aimed at enhancing the functionality of substrate-based chains in the Polkadot ecosystem with plugin-like functionality. + +By using the ink! programming language, third party developers can extend the core functionality, while focussing on the domain logic. + +The total ask for this proposal is $100,000 and it is planned to have a subsequent development to use this functionality within Genesis DAO (see the last grant, [future plans section](https://github.com/w3f/Grants-Program/blob/master/applications/GenesisDAO.md#future-plans)). + + +## Project Details + +### Introduction +A group of people surrounding Ken Thompson and Dennis Ritchie were quite busy at Bell Laboratories shaping the world as we know it today. They invented a milestone in programming languages — C, the breakthrough operational system Unix, the first shell, UTF-8 and a long list of others that alone would have been enough to receive a Turing award. + +How were they so productive? Of course, the density of talent at Bell Labs was as high as within the Beatles (before John married) — but one tiny detail helped drive them. And that can be summed up in one word: focus. Finding out what holds the application together in its innermost folds and excelling at that. It takes writing programs that do one thing and do it well. Today, this set of guiding principles is popularly known as the Unix philosophy. + +This fundamental building block of system design is what guides Substrate development today. The Polkadot ecosystem is a set of domain-specific chains that focus on building the infrastructure for the web3 universe. + +The ink! programming language can be run on Substrate chains, either as a [core value proposition](https://use.ink/how-it-works#use-case-1-smart-contracts-as-first-class-citizens) - with the chain being an ecosystem for protocols developed in ink! on top of it - or as [second class citizens](https://use.ink/how-it-works#use-case-2-smart-contracts-as-second-class-citizens) - with protocols being able to build on top of the domain logic. + +*Stylograph* introduces a third use-case by utilizing ink! as a configuration language to alter the domain specific language itself by introducing a simple and straightforward framework to inject loosely-coupled hook points into your pallets that will call smart contract functionality in registered contracts on the contracts pallet. + + +### Motivation +Deep Ink Ventures is building a system parachain for the Polkadot ecosystem that is building infrastructure for Decentralized Autonomous Organizations - Genesis DAO. + +At *Genesis DAO* we are committed to the Unix philosophy. + +We focus on the DAO management with the core components of creating and running DAOs, overseeing token issuance and DAO treasury and having a rock-solid proposal and voting infrastructure. + +However, DAOs can have small and granular requirements that do require small tweaks and adjustments. Sometimes on-top protocols like Yield Aggregators require additional functionality. Some of those changes may be deal breaking for technical use cases or legal reasons and therefore a hard requirement for newly founded DAOs. + +The core team ultimately has to decide what features are reasonably part of an unbloated core and there is no one-size-fits-all solution to a lot of problems. This is where Stylograph comes to the rescue. + +### Framework Components Overview + +The following is an overview of the architecture we build and is merely to sketch the scope and general concept. Implementation details may vary. + +#### pallet_stylograph +This pallet acts as an abstraction layer on top of pallet_contracts in order to conveniently create callback based implementations. + +The pallet will have initial support for *ink!*. The concept is easily extendable for other languages such as *Solidity* or *ask!* that can be added. + +![image](https://user-images.githubusercontent.com/120174523/236872194-471198c3-48d8-4acc-842b-0ac450929908.png) + + +Since Substrate does not know about the structure of smart contracts deployed in ink! beforehand, Substrate developers utilizing Stylograph need to register the function signature they want to support for callbacks. + +This is a one-liner in the chain specs: + +Stylograph is now aware of a function given by signature, function name or trait definition and knows its associated gas limit. + +![image](https://user-images.githubusercontent.com/120174523/236872381-418dacb9-e776-4f5f-af0a-1c133196c2dc.png) + +With the callback defined, the core developers now can add callback functions into their pallets that extension developers can utilize. + +For example, the function above may alter the original vote in order to come up with a more complex algorithm (and it is therefore valuable to carefully select the arguments for the callback function for extension developers to be flexible). + +An example might be something like this: + +![image](https://user-images.githubusercontent.com/120174523/236872439-2b1cc9aa-0a5f-4982-9fc2-723828e7cfb5.png) + + +The next part is the registration of extensions by accounts - the second argument given in the callback above. + +The Substrate node implementation can decide how they want to interpret this - e.g. if the extensions are per account or if the account represents an entity on the chain. The latter is true for _Genesis DAO_ where the account needs to be the owner of the DAO. Each DAO can register its own hookpoints to tweak the core to its needs. + +![image](https://user-images.githubusercontent.com/120174523/236872530-d4cd6aec-03f5-4221-8cd8-a67a2b04da5f.png) + + +The framework now has all the information at hand to execute a fully abstracted _pallet_contracts::bare_call _and to handle errors associated with it: + +1. The user calls the extrinsic of the implementing pallet. In the case of GenesisDAO that might be the _dao_votes_ pallet to intercept the voting process in order to alter the majority voting to a different decision system. +2. This pallet executes the callback that takes the information given from the _dao_votes_ panel and looks up the callback definitions registers. +3. It constructs a call to the ink! contract defined. + +![image](https://user-images.githubusercontent.com/120174523/236873188-5fc04a21-6d59-41c3-921a-37a8e2ece739.png) + +The gas fees are therefore called by the person utilizing the functionality - the user calling the initial extrinsic. + + +#### ink! Stylograph Facade Builder + +The aforementioned information is enough to automagically generate a full boilerplate contract as template that Substrate chain developers can use to deploy a sample contract and to write a macro that defines the interface that the runtime expects. + +This contract can be released to the extension developer community to use as a boilerplate template. They can as well import the trait for the contract to be sure that they are compatible with the specs defined by the runtime. + +![image](https://user-images.githubusercontent.com/120174523/236872845-248bc23e-a96b-4008-8e9e-6d6cf1756d35.png) + +We therefore are building a CLI tool to package a versioned ink! crate with installation steps and base documentation that can be published with a new runtime release of the chain to give protocol and extension developers a headstart to extension development. Both the chain and the contract will depend on those traits as dependency to identify the interface. + +![image](https://user-images.githubusercontent.com/120174523/236881416-f7d622dc-2993-4b84-99c3-4b1835970372.png) + +## Additional Development +As this is planned to be part of our to-be-planned-system-parachain, we are as well pushing the development of the main chain within this proposal. + +### Token Transfer +Currently we rely on wallet extensions and polkadot.js.org to transfer DAO tokens around that reside on Genesis DAO. We have a primitive frontend UI in our MVP but would like to expand this to a more user friendly interface. + +We have already created some designs to show the direction, but this would include full wireframes, designs + additions to our backend services and, of course, the dApp: + +![image](https://github.com/deep-ink-ventures/Grants-Program/assets/120174523/f5c0bdf2-1600-4264-bda5-75a7708c1459) + +## Council Management +We’ve already created the multisignature part of council and treasury management within our product / wireframe and design department and want to roll out a Gnosis Safe - Style interface for this as part of the treasury management. + +We are using pallet_multisig for this and currently council members need to go via polkadot.js.org, not the most user friendly interface in the world. + +This would again include the full wireframes, desings and code changes in the backend and frontend. We have already implemented the multisig part. + +![image](https://github.com/deep-ink-ventures/Grants-Program/assets/120174523/68608920-3a08-4658-bb84-2f1852b42053) + +## DAO Dashboard Add-On + +We are createing a few designs to make the DAO Dashboard more friendly and intuitive for users and want to do the frontend implementation as well as the respective adjustments to the APIs of our backend service. + +![image](https://github.com/deep-ink-ventures/Grants-Program/assets/120174523/3d1a5587-3bef-4d84-ad96-1a5c99c0d4c8) + + +## Ecosystem Fit + +While we have drafted this pallet with the next iteration of the Genesis DAO chain in mind ([here are some planned plugins and extensions for inspiration](https://docs.google.com/document/d/1yyEBa43plj-PzlrEnK6JT5CKqyvBDUrYiR1N6984fhk/edit#heading=h.nfot0twi37l)), the presented functionality is carefully abstracted into a reusable component system. + +Stylograph is to Substrate what plugins and and extensions were for CMS, Shops in web2 - a smooth way for third parties to extend the core functionality for a chain. It enables Substrate developers to concentrate on doing their domain logic well whilst their users and protocols building on top maximize flexibility and time-to-market. + +You can think of this as the inverse to chain extension. While chain extension gives plugins a way to interact with the underlying core logic, stylograph gives chain developers an easy framework to make their core extendable with plugins and extensions via smart contracts. They can be used by any chain that wants to have a growing extension ecosystem. + + + +## Team + +### Contact + +- **Contact Name:** Jakob Drzazga +- **Contact Email:** admin@deep-ink.ventures + +### Legal Structure + +- Deep Ink Ventures GmbH, registered with the commercial register at the local court of Berlin, HRB 247342 + + +## Development Roadmap + +### Overview + +- **Total Estimated Duration:** 4-5 month +- **Full-Time Equivalent (FTE):** 3-4 FTE +- **Total Costs:** $ 100,000 + + +## Development Status :open_book: + +The development will happen on https://github.com/deep-ink-ventures/genesis-dao-node as we test the functionality in a full chain, but the pallet will be released as it's own crate. + +## Development Roadmap :nut_and_bolt: +### Milestone 1 + +- **Estimated duration:** 3 month +- **FTE:** 3-4 +- **Costs:** 70,000 + +| 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 can integrate the pallet and start working with | +| **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.** | Benchmarking | We will provide benchmarking & weights for the pallet | +| **0e.** | State of the art Tech Stack | We will use next.js/react for all frontend components, python / django for the backend services and rust for developing the substrate components| +| 1. | Pallet Development | Develop the pallet as specified within the `pallet_stylograph` section above. | +| 2. | Frontend Integration: Dashboard Add-On | Develop full wireframes and designs + Frontend, Backend integration, deployed on https://genesis-dao.org. | +| 3. | Frontend Integration: Token Transfer | Develop full wireframes and designs + Frontend, Backend integration, deployed on https://genesis-dao.org. | + + + +### Milestone 2 + +- **Estimated Duration:** 2 month +- **FTE:** 3-4 +- **Costs:** 30,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 can integrate the pallet and start working with | +| **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.** | State of the art Tech Stack | We will use next.js/react for all frontend components, python / django for the backend services and rust for developing the substrate components| +| 1. | Facade Builder | Develop the code generator for smart contracts as specified above in the `ink! Stylograph Facade Builder` section. | +| 2. | Refrence Implementation | We will provide a sample implementation alongside with `pallet_contracts` on the Genesis DAO test chain to demonstrate the functionality. | +| 3. | Frontend Integration: Councils Management | Develop full wireframes and designs + Frontend, Backend integration, deployed on https://genesis-dao.org. | + + +## Future Plans +Our future plan is to include (and therefore maintain and extend) this pallet within our Genesis DAO Chain. The exact game plan is laid out [here](https://docs.google.com/document/d/1yyEBa43plj-PzlrEnK6JT5CKqyvBDUrYiR1N6984fhk/edit). diff --git a/applications/SubDAO-Chrome-Extension.md b/applications/SubDAO-Chrome-Extension.md index 9d6aa17c9ca..0408a53932c 100644 --- a/applications/SubDAO-Chrome-Extension.md +++ b/applications/SubDAO-Chrome-Extension.md @@ -1,6 +1,5 @@ -# W3F Open Grant Proposal +# SubDAO Chrome Extension -* **Project Name:** SubDAO Chrome Extension * **Team Name:** [SubDAO Labs](https://github.com/subdao-network) * **Payment Address:** 3FcJjvzazcpgmJkesdAfx333fyCudxuAe7 @@ -23,7 +22,7 @@ We are the team of SubDAO Labs, and we are trying to build the ecosystem for DAO SubDAO Chrome Extension provides several features, such as Polkadot Wallet, Social Network Message, and DAO Management. ![](https://raw.githubusercontent.com/SubDAO-Network/graphics/main/start.png) -**Polkadot Wallet** +**Polkadot Wallet** A wallet is integrated as an extension of chrome, and it provides wallet management. ![](https://raw.githubusercontent.com/SubDAO-Network/graphics/main/wallet.png) @@ -35,7 +34,6 @@ It supports Twitter and Facebook messages. Thanks to [MaskBook](https://mask.io) The main goal of creating SubDAO Chrome Extension is to help users to manage their DAOs with a better user experience. ![](https://raw.githubusercontent.com/SubDAO-Network/graphics/main/DAO.png) - ### Ecosystem Fit * Where and how does your project fit into the ecosystem? @@ -78,37 +76,40 @@ There are no similar projects in the Polkadot ecosystem yet, and even we already The team is the one who applied SubDAO. -**Qiang** - - Over 13 years of experiences in Software Development - - Chief Solution Architect in Tencent - - Former Team Lead in IBM - - Core Developer of Smart Cloud / HSLT - - Code Contributor of KVM - - Community Contributor in RedHat +**Qiang** + +* Over 13 years of experiences in Software Development +* Chief Solution Architect in Tencent +* Former Team Lead in IBM +* Core Developer of Smart Cloud / HSLT +* Code Contributor of KVM +* Community Contributor in RedHat + +**Marvin Tong** -**Marvin Tong** - - Founder and CEO of Phala Network - - Former Product Manager in Tencent - - Former Product Manager in DiDi +* Founder and CEO of Phala Network +* Former Product Manager in Tencent +* Former Product Manager in DiDi -**Dajun** +**Dajun** - - Over 12 years of experiences in Development - - Former Senior Software Engineer in Alibaba - - Core Developer of Wetez and StaFi.io +* Over 12 years of experiences in Development +* Former Senior Software Engineer in Alibaba +* Core Developer of Wetez and StaFi.io -**John Xie** +**John Xie** - - Full-stack Developer - - Over 15 years of experiences in Development and Management - - Has plenty of experience in Software Development and Blockchain Development - - Currently, focus on Cross-chain technologies +* Full-stack Developer +* Over 15 years of experiences in Development and Management +* Has plenty of experience in Software Development and Blockchain Development +* Currently, focus on Cross-chain technologies -**Tallone** - - Full-stack Developer - - Over 20 years of experiences in Product Development and Management - - Has plenty of experience in Software Architecture - - Currently focused on Blockchain Development and Cross-chain Technologies +**Tallone** + +* Full-stack Developer +* Over 20 years of experiences in Product Development and Management +* Has plenty of experience in Software Architecture +* Currently focused on Blockchain Development and Cross-chain Technologies ### Team Code Repos @@ -144,7 +145,7 @@ The Social Network provides the feature to post encrypted messages on Twitter an ### Milestone 1 - The first published version * **Estimated Duration:** 1 month -* **FTE:** 3 +* **FTE:** 3 * **Costs:** 9,000 USD | Number | Deliverable | Specification | @@ -167,9 +168,8 @@ The Social Network provides the feature to post encrypted messages on Twitter an ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** We get this information from the w3f website. * We have made the SubDAO Network, and an open grant has been accepted. * Thanks to the Maskbook team who builds Mask book. - diff --git a/applications/SubDAO_Network.md b/applications/SubDAO_Network.md index 64d3dccee7c..0c3067a5ae8 100644 --- a/applications/SubDAO_Network.md +++ b/applications/SubDAO_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# SubDAO -* **Project:** SubDAO * **Proposer:** [SubDAO Labs](https://github.com/subdao-network) * **Payment Address:** 3FcJjvzazcpgmJkesdAfx333fyCudxuAe7 diff --git a/applications/SubDAO_PolkaSign.md b/applications/SubDAO_PolkaSign.md index 20f303cf282..711c72b98b2 100644 --- a/applications/SubDAO_PolkaSign.md +++ b/applications/SubDAO_PolkaSign.md @@ -1,6 +1,5 @@ -# W3F Open Grant Proposal +# PolkaSign -* **Project Name:** PolkaSign * **Team Name:** [SubDAO Labs](https://github.com/subdao-network) * **Payment Address:** 0x0c105bA504D1905bb47EeA57FA8694893bDEd27f @@ -10,27 +9,23 @@ The previous application [SubDAO Network Application - https://github.com/w3f/Gr ### Overview -The PolkaSign is a web3.0 app for electronic agreements built on top of Polkadot Ecosystem. The electronic agreement is well-known in web2.0 instead of paper agreements used thousands of years in historical time. With electronic agreements, commercial activities become much more efficient and have a lower cost than ever. The whole human world is benefiting from electronic agreements in the past 30 years. While with more and more electronic agreements signed, more and more issues are exposed. Such as electronic agreements are stored in a centralized system, fraud in electronic agreements, and so on. With PolkaSign, anyone can sign an electronic agreement with whoever he/she wants. To sign an electronic agreement, you just need to upload your agreement document, and sign it in PolkaSign, then share the link to the co-signer. +The PolkaSign is a web3.0 app for electronic agreements built on top of Polkadot Ecosystem. The electronic agreement is well-known in web2.0 instead of paper agreements used thousands of years in historical time. With electronic agreements, commercial activities become much more efficient and have a lower cost than ever. The whole human world is benefiting from electronic agreements in the past 30 years. While with more and more electronic agreements signed, more and more issues are exposed. Such as electronic agreements are stored in a centralized system, fraud in electronic agreements, and so on. With PolkaSign, anyone can sign an electronic agreement with whoever he/she wants. To sign an electronic agreement, you just need to upload your agreement document, and sign it in PolkaSign, then share the link to the co-signer. The PolkaSign is developed with Substrate Framework based on the SubDAO Network, which can be replaced with any Substrate Based Chains, and serves any kind of orgs with electronic agreements. The goal of PolkaSign is to provide electronic agreements in a web 3.0 way, to replace the systems in web 2.0. ### Project Details -PolkaSign combines blockchain and decentralized storage to provide a reliable electronic agreements platform. With the decentralized storage system, such as IPFS, Swarm, or Crust in Polkadot ecosystem, provides the storage for the agreement files, at the current state, only PDF is supported. The information of agreement, including signature, signer, agreement files list, etc., is written with smart contract on the blockchain. The PolkaSign provides a dapp to handle agreement files, co-signer, and links, to interact with decentralized storage and smart contracts on the blockchain. The smart contracts of PolkaSign are based on ink!, any substrate-based chain can adopt these smart contracts easily. +PolkaSign combines blockchain and decentralized storage to provide a reliable electronic agreements platform. With the decentralized storage system, such as IPFS, Swarm, or Crust in Polkadot ecosystem, provides the storage for the agreement files, at the current state, only PDF is supported. The information of agreement, including signature, signer, agreement files list, etc., is written with smart contract on the blockchain. The PolkaSign provides a dapp to handle agreement files, co-signer, and links, to interact with decentralized storage and smart contracts on the blockchain. The smart contracts of PolkaSign are based on ink!, any substrate-based chain can adopt these smart contracts easily. ### Workflow Below is the workflow of how to use PolkaSign. Alice wants to sign an agreement with Bob, so she creates an electronic agreement with PolkaSign, and the electronic agreement files are stored in the decentralized storage system. Then Alice adds Bob's wallet address as co-signer, and sign the contract with her private key. After that, Alice shares the information of agreement with Bob. When Bob launches PolkaSign with his wallet, he will find the very agreement waiting for him to sign. Everything is done when Bob approves and signs the agreement send from Alice in PolkaSign. - - ![Flow-2021-07-21-2311](https://raw.githubusercontent.com/WannaM/graphics/main/Flow-2021-07-21-2311.png) - - ### Design -The home page shows the list of agreements in different statuses. The current waiting for signing agreements will be display as default, and you can switch the list by tabs or filter button in the left panel. The agreement file info, the status, and the progress of the agreement are shown in the detailed info of each agreement. The draft design of PolkaSign is shown below. +The home page shows the list of agreements in different statuses. The current waiting for signing agreements will be display as default, and you can switch the list by tabs or filter button in the left panel. The agreement file info, the status, and the progress of the agreement are shown in the detailed info of each agreement. The draft design of PolkaSign is shown below. ![Overview-2021-07-21-2052](https://raw.githubusercontent.com/WannaM/graphics/main/Overview-2021-07-21-2052.png) @@ -42,19 +37,10 @@ The second step is to add co-signers. Add any number of co-signers by filling in ![AddSigner-2021-07-21-2052](https://raw.githubusercontent.com/WannaM/graphics/main/AddSigner-2021-07-21-2052.png) - - The last step is to review the contract. When everything is ready, sign it with your wallet and share the link with co-signers. - - ![Review-2021-07-21-2052](https://raw.githubusercontent.com/WannaM/graphics/main/Review-2021-07-21-2052.png) - - - - - ### Ecosystem Fit * Where and how does your project fit into the ecosystem? @@ -95,24 +81,26 @@ The project meets the need of signing contract with decentralization, immutabili The team is the one who applied SubDAO. -**Qiang** - - Over 13 years of experiences in Software Development - - Chief Solution Architect in Tencent - - Former Team Lead in IBM - - Core Developer of Smart Cloud / HSLT - - Code Contributor of KVM - - Community Contributor in RedHat +**Qiang** -**Marvin Tong** - - Founder and CEO of Phala Network - - Former Product Manager in Tencent - - Former Product Manager in DiDi +* Over 13 years of experiences in Software Development +* Chief Solution Architect in Tencent +* Former Team Lead in IBM +* Core Developer of Smart Cloud / HSLT +* Code Contributor of KVM +* Community Contributor in RedHat -**Dajun** +**Marvin Tong** - - Over 12 years of experiences in Development - - Former Senior Software Engineer in Alibaba - - Core Developer of Wetez and StaFi.io +* Founder and CEO of Phala Network +* Former Product Manager in Tencent +* Former Product Manager in DiDi + +**Dajun** + +* Over 12 years of experiences in Development +* Former Senior Software Engineer in Alibaba +* Core Developer of Wetez and StaFi.io ### Team Code Repos @@ -129,7 +117,7 @@ We have already designed some UI/UX as the shown previous section, and the rest ## Development Roadmap :nut_and_bolt: -We planned two major versions. +We planned two major versions. Version 1: The goal of first version is to provide a usable PolkaSign, the users can upload PDF agreement files and co-sign with other signers. It contains the features of store agreement files in decentralized storage, sign contract with smart contract, sharing the contracts waiting for sign. @@ -137,18 +125,16 @@ Version 2: The goal of second version is to provide a common PolkaSign for other ### Overview -In this application, we planned to provide the first version of PolkaSign. The main features are 1) store agreement files in decentralized storage, 2) sign contract with smart contract and 3) sharing the contracts waiting for sign. It will contains smart contract with ink!, web app as client and codes to interact with decentralized storage system. +In this application, we planned to provide the first version of PolkaSign. The main features are 1) store agreement files in decentralized storage, 2) sign contract with smart contract and 3) sharing the contracts waiting for sign. It will contains smart contract with ink!, web app as client and codes to interact with decentralized storage system. * **Total Estimated Duration:** 2 month * **Full-Time Equivalent (FTE):** 2 * **Total Costs:** 15,000 USD - - ### Milestone 1 - The first usable version * **Estimated Duration:** 2 month -* **FTE:** 2 +* **FTE:** 2 * **Costs:** 15,000 USD | Number | Deliverable | Specification | @@ -170,7 +156,7 @@ In this application, we planned to provide the first version of PolkaSign. The m ## Additional Information :heavy_plus_sign: -**How did you hear about the Grants Program?** +**How did you hear about the Grants Program?** We get this information from the w3f website. * We have made the SubDAO Network, and an open grant has been accepted. diff --git a/applications/SubGame_Network.md b/applications/SubGame_Network.md index bfba7857e8f..9676d656f7f 100644 --- a/applications/SubGame_Network.md +++ b/applications/SubGame_Network.md @@ -1,6 +1,5 @@ -# Open Grant Proposal +# SubGame Network -* **Project Name:** SubGame Network * **Team Name:** [SubGame-Network](https://github.com/SubGame-Network) * **Payment Address:** 3CK6HN4y2ZEKX7JMfdegds7B7GrUSmv65c @@ -121,16 +120,16 @@ No Legal Entity | 1a. | SubGame Node | Provide node compilation and installation instructions, start the test network| | 2a. | pallet-chips | The Chips module has been developed and you can use Chips to participate in the game | | | Storage: | `Chips get(fn get_chips): map hasher(blake2_128_concat) T::AccountId => u32;` | -| | Function: | 1)`pub fn transfer_chips(origin,chips:u32)->dispatch::DispatchResult`

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

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