Polkadot ink! Ecosystem Grants

👋 Introduction

Ecosystem Grants are part of the Ink!ubator, a holistic bounty program that evolves ink! smart contacts, funded and approved by the Polkadot community/treasury. Initially pioneered by Astar Network, now includes Curators from Parity, Phala Network, Brushfam, Aleph Zero teams. As WASM is the future of smart contracts and one of the key differentiators of Polkadot, ink!ubator believes the growth of its field will greatly empower Polkadot ecosystem.
Read more - Bounty

Ecosystem Grants focuses on funding core ink! infrastructure products and ink! canary dapps, applications aimed to demostrate ink! potential and its superiority compared to other smart contract languages and ecosystems.

Guidelines

Anyone is welcome to apply for a grant. This program funds projects that are dedicated to ink! ecosystem growth. We focus on strong technical ideas that contribute to ink! infrastructure, demonstate ink! potential, and unveil applicable business side thus growing the ecosystem.

Generally, your project will have better chances to be accepted if:

  • It clearly shows the advantage of ink! over other smart contract languages (e.g. Solidity)
  • Your idea is innovative and contributes to the general growth of web3, Polkadot and ink! ecosystem. We would usually prefer innovation over duplication of what already exist on EVM.
  • 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 if applicable.
  • 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.

Additionally, it must fulfill the following requirements:

  • All code produced as part of a grant must be open-sourced, and it must also not rely on closed-source software for full functionality. We prefer Apache 2.0, but GPLv3, MIT or Unlicense are also acceptable.
  • We do not award grants for projects that have been the object of a 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.

We require all projects to create documentation that explains how their project works. At a minimum, written documentation is required.

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.

Project Ideas

The main acceptance criteria of any submitted project would be its impact on the ink! ecosystem.

We would like to advise 3 following categories:

Industry Canary dApp

A Canary dApp is one that could be deployed on to a value bearing network, but may not necessarily be battle hardened enough for serious use cases. They are meant to be a step beyond simple tutorials while still being self-contained enough to provide a useful reference for developers building production grade dApps. Some examples:

  • Lending application that allows users to earn interest on deposits and borrow assets with a variable or stable interest rate. (2 types)
  • Liquid staking a liquid staking provider takes token deposits, stakes those tokens, and gives the depositor a receipt which is redeemable for the staked tokens.
  • Aggregator that unites separate decentralized protocols and aggregates liquidity from a variety of decentralized exchanges to facilitate cost-efficient transactions.

Ink! Cutting-edge Showcase

This category implies developing full-stack application that clearly demonstrates the advantages of ink! over other smart contract languages(e.g. Solidity). In this category you should focus on opening the full potential of ink. The case doesn't necessarily needs to be business oriented. However it should clearly and visually demostrate superiority of ink. You can use following aspects as indicators:

  • gas
  • smart contract size (find a use case where the size of smart contract will be smaller then solidity - application with complex calculations)
  • code writing experience (how comfortable to write code)
  • debugging experience

Ink! Infrastructure

On this stage ink! ecosystem lacks a lof of infrastructure. We welcome you to be innovative and submit your ideas. We will prefer ideas that add differentiation to Polkadot/ink! ecosystem, rather then tools that simply duplicate EVM. Examples of successful infrastructure products:

Support

The scope of our Grant Program 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 ink! on the use.ink website.

Also, you can visit community support channels:

Team

Ink!ubator Curators

The curators consists of individuals, and are responsible for evaluating bounty applications and providing feedback on these.

  • Sam Ruberti from Parity Technologies: Sam Ruberti is a Senior Rust Developer with ink! and has over twelve years of experience delivering full-stack products for companies including Bloomberg, Peloton, and Clear, and five years of experience building full-stack Dapps in production environments. He has built microservices, DeFi platforms, NFTs, and contributed to open-source libraries for Ethereum.

  • Sota Watanabe Astar Foundation: Sota Watanabe is the founder of Astar Network. He joined the web3 space in 2015 and started developing Astar Network in 2019. Apart from his achievements, he is a director of the Japan Blockchain Association and used to be a blockchain researcher at the University of Tokyo and a task force member of Trusted Web led by the Japanese government. In addition to that, he was chosen for Forbes 30 Under 30 Asia in the IT division and Forbes 30 Under 30 Japan.

  • Hernando Castano from Parity Technologies: Hernando is a Core Developer at Parity Technologies. Hernando joined the blockchain space in 2017, initially curious about the world of smart contracts on Ethereum. In 2019, Hernando joined Parity Technologies to work on the Parity Ethereum client, and has since transitioned to the team working on the ink! programming language.

  • Markian Ivanichok 727 Ventures: Founder & CEO at 727.ventures, Brushfam & Dedali Metaverse. Web3 entrepreneur, Software Engineer. Brushfam onboards businesses to Polkadot WASM. Projects: Openbrush(Openzeppelin of WASM ink!), Typechain for ink!, sol2ink (transpiler from solidity to ink!), and substrate/ink! contribution itself. Also, WASM conference, was the first web3 WASM conference and gathered ~1000 participants.

  • Hang Yin from Phala Network: Co-founder and CTO at Phala Network. 5 years of Web3 core development and entrepreneur experience. Author of Phala Network Technical Whitepaper. Lead the team to build an off-chain computing protocol based on ink! and Substrate with 30k online servers. Ex-Googler on Machine Learning before joining Web3.

  • Michał Świętek , Development Lead at Aleph Zero: For a couple of years, Michał has been fully devoted to the Aleph Zero project. From co-designing novel consensus mechanisms, and writing the first lines of code in core repositories, to the high-level architecture of Aleph Zero node implementation.

📝 Process

📢 Payment is made in DOT (on Polkadot).

1. Application

  1. Fork this repository.
  2. In the newly created fork, create a copy of the application template (applications/application-template.md).
  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. Make sure your deliverables present a similar level of detail.
  5. Once you're done, create a pull request in this repozitory. The pull request should only contain one new file—the Markdown file you created from the template.

2. Application Review

  1. Curators can (and usually do) 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, 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 3 approvals, 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

Milestones are to be delivered on the Grant Milestone Delivery repository following the process described therein.

Changes to a Grant after Approval

  • Accepted grant applications can be amended at any time. However, this necessitates a curators reevaluation and the same number of approvals as an application. 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. If Curator creates the termination PR, only 2 more approvals are required).

💡 Help

Real-time conversation

We have Matrix/Element channels for real-time support regarding running bounties. Join the conversation.

Other channels