Jun 22, 2017 · 4 min read

Today we are launching Byteball Grants Program. We’ll pay for work that improves the ecosystem. We want the contributors to both come up with new ideas and realize them.

Similar programs have worked or are still working within other projects such as Dash and Ethereum and proved their success, e.g. Casper and MetaMask came out of Ethereum DEVgrants program.

The grants will be paid from our Community Fund which is funded by donations and undistributed bytes and blackbytes.

The process of awarding the grants will be as public and transparent as possible. Below are the rules, they might be amended in the future and evolve as we gain experience. If you have any ideas how to make the platform better and ready to do it yourself or with your team, feel free to apply.

Byteball Grants

Grants are paid for work that contributes to Byteball ecosystem. The work is not limited to development only, it can be any other work (such as marketing, promotion) that potentially adds value to Byteball platform as a whole.

Grants are paid out of the Community Fund.

The general procedure is as follows:

  1. Applicant(s) come up with an idea that can be realized by the applicant(s) and would potentially add value to the platform
  2. Applicant(s) draft a pre-proposal and offer it for public discussion. The pre-proposal includes the what and why of the work as well as milestones and requested funding.
  3. After public discussion and based on community feedback, the applicant(s) optionally amend the pre-proposal and submit a final proposal.
  4. The proposal is voted by the community fund trustees and approved based on 3-of-4 majority, or rejected.
  5. The applicant(s) publish regular updates about their ongoing work and the funds are released based on achieved milestones.

Proposals and pre-proposals

Proposals and pre-proposals have the same content requirements, the difference being only that pre-proposals are submitted to the community for public discussion and can be amended many times to incorporate feedback from the community, while proposals are final formal documents that necessarily trigger trustee vote.

It’s up to the applicant(s) to decide when their pre-proposal has matured to be submitted as a finished proposal but at least a week of public discussion is recommended.

Applicant(s) can withdraw their pre-proposal at any time for any reason.

Proposals and pre-proposals should be published as an online document (google doc, etc) and a link to the document, as well as its summary, should be published in Slack channel #grants. It is recommended to discuss the pre-proposal in a Slack thread started by the pre-proposal.

Content of (pre)proposal

Each (pre)proposal description should include:

  1. What will be done, what are the deliverables
  2. What problem it solves
  3. How the project contributes to the Byteball ecosystem
  4. Timeline and milestones: when and what parts of the project will be ready. Small projects include only one (final) milestone
  5. Requested payment schedule in GB, GBB, and fiat. It must be linked to milestones and should specify how much should be paid against completion of every milestone, plus optionally one pre-payment that should be released immediately after the proposal is approved and before its implementation is started. The schedule can contain payments in fiat e.g. if the applicant’s costs are in fiat, it will be converted to GB or GBB at the time of payment at then-current rates.
  6. Total budget
  7. Team member(s) and their roles in the project and backgrounds

Depending on the nature of the proposal, before a pre-proposal is submitted for the first time, a research should be done to show that what is proposed is doable.

Discussion of pre-proposal

Any community member can comment on the proposal, say how would he/she vote, suggest improvements and amendments.

Final proposal and vote

After discussion the applicants optionally amend their proposal and submit it for vote to the trustees. Trustees vote is based on the merits of the proposal as well as the available funds. Trustees take into account the community feedback during discussion.


A rejected proposal can be submitted again after making amendments and going through a new public discussion.

Reporting and payment

After a proposal is approved, the applicant(s) start working on it. When milestones are achieved, the applicant(s) publicly announce the achievement of the milestone in #grants and request the trustees to release the payment bound to this milestone. Both community members and the trustees evaluate the results of the work and the trustees release the payment within the following 7 days if they find that the milestone was actually achieved.

Acceptance guidelines

  1. For-profit projects are generally not accepted but can be considered if they are long term and significantly improve the ecosystem
  2. Requesting a pre-payment is discouraged unless it is dictated by the nature of the project
  3. Anonymous team members are OK but requesting a prepayment is even more discouraged in this case
  4. Do not duplicate the work of other published (pre)proposals
  5. If development, the work must be open source and under any free license during the entire lifetime of the project
  6. Creative work, documentation, etc should be released under any free license (such as Creative Commons)
  7. Most projects should last less than 3 months


Smart payments made simple


Written by


Smart payments made simple



Smart payments made simple

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade