Jet platform mechanics

Updates:
04-Jan-2021

  • Update the logic of the conditional rewards calculation with allowing for the total percentage of the allocation used
  • Added explanations on the calculations to the tables

This proposal is a description for the initial functionality of the Jet platform, processes around it and voting mechanics. It is expected that the readers are familiar with Aurora staking proposal.

General considerations

As it was stated by the DAO previously, 200M AURORA tokens are devoted to the community treasury. AURORA token holders should be able to decide on the distribution of these tokens to the initiatives and projects that are planning to launch on Aurora. To simplify the interaction with this treasury, Jet platform is developed. Currently (30-Dec-2021) Jet is under development and ready for around 20%, so there are many flows that can be shown, although mechanics can be updated or added.

Note: from the previous DAO voting it was clear that the platform should be created, so Aurora Labs commenced the development

The basic idea is to reuse the mechanics of the crowdfunding platforms, like Kickstarter. However, since users are not transferring their AURORA tokens to the projects, but voting on the distribution from the community treasury it was decided to introduce periodicity in the allocations. So, Jet is operated within seasons. Each season is a complete cycle of applications - voting - distribution of the community grants. A season lasts approx. 2 months, application and voting phases lasting around 1 month each. Season mechanics is tightly coupled with AURORA staking.

Roles

There are three main roles for people interacting with Jet:

  1. Project. This role represents a user or set of users willing to receive an allocation from the community treasury.
  2. User. This role represents an AURORA token holder with VOTE tokens available for voting for projects in the voting phase.
  3. Curator. This is a technical role of the maintainers of the Jet platform.

Curators exist to simplify project and user journeys within Jet platform. Their goal is to handhold projects during the process of application and updating the statuses; and help users to obtain relevant information about the projects. Curators also responsible for providing aggregated information about seasons and winning/loosing projects; producing educational materials.

Project flow

Project flow consists of the following stages:

  1. Application. The project should collect all the relevant info about the proposal and submit it through the submission form.
  2. Curators’ review. After the submission, the project is not automatically published on Jet. On contrary, it is delivered to Curators in a draft form. Curators help the project to update the submission with all the knowledge they have. The goal of the review is to help the projects create a meaningful application with enough details.
  3. Curators’ approval. Once the application is in the good shape, curators approve it and it will be listed during the voting phase.
  4. Voting. At this stage the project owners are waiting for the community voting.
  5. Execution. In case the voting is successful, the project gets a grant and is able to execute through proposed roadmap.
  6. Reporting. At specific milestones, set by the project at the application stage, the project owners should report the progress. Together with curators project owners review the progress and publish a report. Curators are responsible for assigning the scores to the chosen KPIs.

Note: It is expected that there would be a large inflow of the submissions on Jet. Because of this it would be extremely complicated for the users to assess the submissions if these are done in the unmoderated way. Because of this reason, there’s a step 3 introduced in the above plan. Over time it is expected that Jet will become fully permissionless, to guarantee the absence of censorship. This would be only possible with the development of profound criteria for the submissions.

Project application

The projects’ application should consist of substantial amount of information:

  1. Description of the project in a free form, with the explanation of the application of the funding and all the relevant materials. Images and videos are supported.
  2. Grant structure. The distribution of the funding between different buckets, see below. Grant structure should be specified for each milestone, including the post-payment.
  3. Milestones of the project and KPIs for each milestone. A project can request funding for arbitrarily time; however, a project should have milestones at lease once per 4 months. During the every milestone project should submit updates and curators should assess the KPIs.

Grant structure

To support thoughtful applications, grants from community treasury should have the bucket structure with different purposes. Each bucket has a weighting coefficient that is applied to calculate for the total cost of the project. Some of the buckets may be allocated in NEAR tokens through the partnership with NEAR Foundation or Proximity Labs.

  1. Operational budget. Allocated in NEAR or AURORA, weighting coefficient 1.5. The part of the grant that is to be spent for salaries, servers, tools and licenses.
  2. Marketing budget. Allocated in staked AURORA for 1 year, weighting coefficient 0.5. The part of the grant that is to be used by the project to do the staked AURORA drops to their users. This can be implemented through depositing AURORA into staking contract on behalf of the other user.
  3. Long-term incentives. Allocated in locked AURORA, weighting coefficient 0.5. The part of the grant that is to be allocated to the project owners in return for the (future) project tokens deposited in the AURORA staking contract as a new stream (see AURORA staking).
  4. Protocol-specific incentives. Allocated in AURORA, weighting coefficient 1. The part of the grant that is to be used as incentives (for example can be used for double farming for AMM protocols). The difference with the operational budget is in the final recipient of the AURORA. In this case this would be Aurora community, not the project team.
  5. Liquidity. Allocated in NEAR or AURORA, weighting coefficient 0.25 for each 3 months. The part of the grant that is to be used by the project to feed AMM pools or set up its’ own operations.

Let’s consider an example of the project requesting funding and the calculation of the weighted size of the grant.

The project was just born on the hackathon and it requires some additional work till release of the main features. The project team proposes one milestone (3 months for development) and splits the grant into two parts: first focused on the finalisation of the development and second—on the rollout.

Bucket Pre-payment, thousands USD Weighted pre-payment, thousands USD Post-payment, thousands USD Weighted post-payment, thousands USD
Operational budget 200 300 100 150
Marketing budget 10 5 30 15
Long-term incentives 100 50 0 0
Protocol-specific incentives 0 0 50 50
Liquidity 500, 3m 125 1000, 3m 250
Weighted budget 480 465
TOTAL 945

The described grant structure though is a complication comparing to the conventional approach, makes the goal of the decentralised ecosystem building much closer: projects spend a bit of additional time thinking through the actual budget; and the users are able to understand how the project would use the allocated funds.

Depending on the total weighted budget of the project and the voting results the decision is made on financing the project.

Voting results calculation

The allocation of the funding from the community treasury to the projects is dependant on the percentage of the VOTEs allocated by the users to the specific project.

Let’s consider this rule in detail on the following example:

Imagine the community treasury allocating weighted $1M for the grants in the current season. Also, there are only three projects that have applied and were approved by curators. Besides that there are 6600 VOTE tokens used for voting (with accounting for the decay of vote tokens, see AURORA staking).

Projects Project 1 Project 2 Project 3 Comment
Requested weighted budget 500 200 500 -
Percentage of season allocation 50% 20% 50% (project budget) / (season allocation)
VOTE allocated 100 3000 3500 Voting results
TOTAL, VOTEs 6600 Sum of all VOTEs
Percentage of VOTE 1.52% 45.45% 53.03% (VOTEs for project) / (total VOTEs)
Funding decision No Yes Yes if VOTE percentage is higher than percentage of the season allocation, then Yes; No otherwise
TOTAL, allocated budget $700k Sum of the budgets for all projects that have passed the voting

NOTE: Depending on the actual budget structure of projects 2 and 3, the actual amount of money allocated to the project may differ from 200 and 500 thousands USD.

NOTE: Within this example, projects totally requested more than it was allocated to the season. Thus, the limit of the available funding introduces the natural competition between projects, which improves the quality of the projects.

Reporting

At it was said earlier, after each milestone the project should report their progress to the community. Project submits a draft report to the curators and together with them a validation of the report is done. Based on the report, curators are assessing the KPIs and assigning the scores. In case the mean score of the KPIs is less than 30%, the funding of the project ends. KPI results of the project influence the user rewards (see below).

Late submissions of the report are treated as the breach of the obligations in front of the community and means immediate halt of the funding (and, potentially blacklisting of the respective stream).

User flow

The active participation of the users is required only on the voting phase. During this phase it is expected that users will do the research of the projects, approved by the moderators, and vote for those projects, which they seem the most relevant for the development of the Aurora ecosystem.

Users are eligible for the rewards for the activity on Jet. The rewards are split in 2 buckets: unconditional and conditional. Unconditional rewards constitute 20% of the user rewards pool. Conditional rewards constitute 80% of the rewards pool. Conditional rewards are split between projects in accordance with their requested weighted budget and distributed with milestone mean KPIs as weighting coefficient. All rewards are distributed between users pro rata depending on the amount of VOTE tokens used.

Unconditional rewards are distributer right after the end of the voting. While conditional rewards are distributed within the lifetime of the project, depending on its milestones and KPIs.

To make the approach more understandable, let’s get back to the example of voting results calculation. Let’s also assume that for this season there are $100k allocated for user rewards. Let’s see how these would be distributed among the users.

Projects Project 1 Project 2 Project 3 Comment
Requested weighted budget 500 200 500 -
Percentage of season allocation 50% 20% 50% (project budget) / (season allocation)
VOTE allocated 100 3000 3500 Voting results
TOTAL, VOTEs 6600 Sum of all VOTEs
Percentage of VOTE 1.52% 45.45% 53.03% (VOTEs for project) / (total VOTEs)
Funding decision No Yes Yes if VOTE percentage is higher than percentage of the season allocation, then Yes; No otherwise
TOTAL, allocated budget $700k Sum of the budgets for all projects that have passed the voting
Allocation efficiency 70% (allocated budget) / (season allocation)
TOTAL, unconditional rewards $20k (20% of $100k)
Unconditional rewards $0.3k $9,09k $10,61k pro rata on the VOTE distribution
TOTAL, conditional rewards, max $56k (80% of $100k)*(allocation efficiency)
Conditional rewards, max - $16k $40k pro rata, based on requested funding
Project KPIs - 70% 50%
Conditional rewards, distributed - $11,2k $20k (conditional rewards, max)*(KPI score)
TOTAL, conditional rewards $31.2

NOTE: in case the project has multiple milestones, conditional rewards are distributed pro rata weighted budget for the milestones.

There are multiple mechanics in the approach above:

  1. Everyone who devotes his time on the voting process will get an unconditional reward
  2. Users that correctly assess which projects will get funding receive additional conditional rewards. This mechanics mitigates lazy behaviour of the users: when the user votes for a random project just to get rewards.
  3. Conditional rewards pool is quite big, but the community is incentivised to vote carefully, since the more season allocation is distributed, the more rewards the users will get. This mitigates the scenario everyone is voting for a small simple project, that for sure would be delivered.
  4. User rewards depend on the project deliverables. This creates a strong bound between the project team and its’ voters: if project performs well, then users are happy.
  5. Users that vote according to the majority votes, will get lower rewards. Indeed, the conditional rewards distribution dependant on the weighted budget. So in the example above, users that have been voting for the project 2 in fact got much lower amount of conditional rewards per VOTE: up to $3.73 per VOTE; while voters of the project 3—$5.71 per VOTE; even though the project 3 performed worse.

Draft designs

Home page:

Project page:

User profile:

6 Likes

Dear Alex,

I read your full articles (both this one and the staking aurora) and have couple of things that havent clear yet. I hope you will notice this and explain for me please.

  1. In the grant stucture, i do not understand the “weight coefficient” that you mention. What is this number affect to the fund, and does this number is from the staking of AURORA that written in the AURORA staking article?

  2. In the example of grant structure, i dont know how to calculate the weighted budget, can you explain more

  3. In the example of user flow, i read that assume we have $100k for reward, so these rewards are also from the community treasury right?

2 Likes

Hi, @meocuksuk !

No, this is a separate thing. The weighting coefficient is described in the Grant structure part. The idea behind it is money for different purposes have different costs. If a project just needs some liquidity to kickstart, then this liquidity should be withdrawn in some time, so this money cost less.

There are 5 points in the grant structure. Just multiply each on the coefficient and add everything together. For the pre-payment the calculation is the following:

200*1.5 + 10*0.5 + 100*0.5 + 0*1 + 500*0.25 = 480

Yes. This is up for the future decisions what would be the split of the community treasury between user incentives and grants, but let’s keep this as a separate topic. I believe there’re other things that will also be included in these 20% of the token supply, like the cost of the development of the platform.

3 Likes

thanks for the information. to the moon

Hello thank you sers for the great beautiful prototype and strong info on the treasury. I was wondering if adding a mechanism to require holders of the VOTE token to be actively engaged in the AURORA staking contract to vote on proposals/grants could be useful? I believe there could be risks from users/projects who stake AURORA just to gain votes for influence on a project they like or may be apart of and if the vote does not go as they planned they may unstake AURORA taking their votes/power with them and that could lead to them sabotaging other proposals without them actively staking . I believe this would overall just add more utility for staking and the AURORA token so users do not just stake to gain votes and then leave once they get the amount they are looking for.

Thanks for the suggestion, @xo30fb .

IMO, punishments are a bit worse incentive rather then pure positive incentives for the active community.

In case people don’t want to take part in the voting, no problem: they might be too busy. According to staking proposal their VOTEs would just decay and they would be able to influence nothing. Moreover, as it said in the collecting stats section, the staking contract will collect the info on the used redeemed and used VOTE tokens. These numbers might play a role in the future governance depending on the DAO decisions.

Just as an example, if the decentalization of the governance proposal will pass, the DAO would need to decide on the weighting formula for the DAO council elections. And it might be something like:

(voting power of the user) = (received VOTE tokens over the period of the previous year) + 5*(used VOTE tokens over the period of the previous year)

The above formula is embracing the value that is provided to the Aurora community of the users that are active.

Also, there are no formulas where the calculations are relative to the total amount of VOTE tokens obtained by AURORA stakers. What matters is only the amount of VOTE tokens that were used for voting for the projects. So, the fact that some people would withdraw AURORA or won’t use VOTE won’t sabotage anything—other votes would just become more valuable.

Also, please remember that to get VOTE tokens, users must stake for the whole period of the season. So there’s no option for a person to stake AURORA, get VOTE tokens, use them and then immediately unstake AURORA. Staker deliberately chooses the period during which he is not able to unstake.

1 Like

Dear Alex,

One more thing i wanna ask about “weight coefficient”. The ratio like 1.5 or 1 or 0.5 is a fixed design number or flexible one? If it is flexible, are there any formula for it? Thank you

It should be fixed for the season. But I expect that after getting some experience with fundings, these coefficients should be updated to incentivise the right behaviour of projects through making it easier for community to determine the real intensions.

1 Like

How does one apply to become a curator? I have a bunch of experience in running hundreds of hackathons and planing their post-hackathon timelines (such a hard thing to do). Would love to be involved in Jet somehow!

2 Likes

Thanks for sharing this, @Jommi. We’ll publish curator position on Aurora Careers page soon, so that would be the main application path.

2 Likes