AIP 29: Bounties for Non-AIP Activities that Add Value to AirSwap


AirSwap sustainability depends on an active member community engaged in the exchange of ideas, culminating in the creation of AIPs aimed to improve project success. Currently, our incentives are limited to rewards for AIP authoring and voting. We propose a bounty system to reward various other activities that improve and grow AirSwap. Bounty categories and associated point rewards are to be continuously created in collaboration with community coordinators.


Bounties reward community members for non-AIP contributions. Bounty creation and submission would run differently and independently from the AIP process, which is reserved for high-level direction and new projects with known requirements and significant scope.

Inline with the AirSwap trading model we propose a “Request For Creativity” model for bounties. Bounty categories, objectives, and goals will be published to the community forum. From there, community members can work independently or collaboratively achieve these objectives.

Each category, objective, or goal will reward up to a certain number of points. Bounties in essence, state a problem space and welcome community members to contribute solutions. For example, bounties could be to “create simple and helpful tools to earn up to X points” or “improve integration examples for up to Y points” or “create and improve project dashboards for up to Z points.”


A bounty is published to “create simple and helpful tools to earn up to N points.” A contributor creates a simple web app allowing community members to see voting status, submits for the bounty, and is distributed up to N points depending on quality and completeness.


  • Coordinators work with the community to define and publish categories and rewards.
  • Categories should be broad enough to allow for creative ideas and solutions.
  • Bounty categories will be posted to the community forum with a call for submissions.
  • First set of categories is to be published by April 22nd.


  • Many submissions can be made to each category and each is eligible for rewards.
  • Submissions are to be made through a Google Form or similar product.
  • Coordinators assess submissions for quality and completeness to determine rewards.
  • If a single submission is authored by multiple contributors the reward may be split.


  • Only AirSwap community members (holding at least 100 sAST) are eligible for bounties.
  • Submissions that include code must be open source and hosted on GitHub or a similar platform.

Should be paid with points rather than treasury. Distribution of treasury should be taken with care and should be based completely on how the project is doing, we need AirSwap to survive for generations, and us being stewards of the treasury need to take this responsibility seriously.

1 Like

thats for the comment! :slight_smile: We had some discussion on this point in discord. The math worked out that given the amount in the treasury to cover these types of activities vs. the expected cost of bounties - it was thought that the impact to the treasury was very insignificant.

I would be interested in hearing what are the benefits to the community members and benefits to Airswap for this question on rewards in points vs rewards in AST… its easy enough to make that change in the AIP. My understanding from the discussions in discord is that most community members wanted bounties in AST.

The biggest benefit is that we retain treasury for the future and not unnecessarily release more tokens in the market. We are all concerned about diluting our currwnt ownership.

Would it not make sense then to have the option for both? some bounties by their nature are one time events - im thinking for example a social media marketing contest - which could reward the winner with points. Other bounties which require more work over time - im thinking for things like dune dashboard maintenance etc. - could get rewarded in sAST.

also wont the potential dilution be really insignificant given 150,000,000 AST in circulation and at most their would be like 25 bounties a year averaging like 1000-2000 ast per bounty? also the amount ast per bounty can change - as the price of AST increase the amount per bounty can always decrease.

It would make sense for larger projects or engagements we could release tokens from the treasury, but that should be an exception rather than a rule

Big fan of this proposal.

Instead of hosting the bounty platform separately (and kind of re-inventing the wheel), we should consider posting bounties on gitcoin. The plus side of this is that you’ll get a lot more exposure to, and engagement from potential contributors, with the downside being a 10% fee on bounty creation.

I do like the idea of priority being given to those with a balance of sAST, but care should be taken not to be too discriminatory against those who don’t have loads of funds available to lock up long term. You’ve also suggested paying out in sAST*, so presumably if you did that, their sAST would not be vested, which almost enforces some loyalty to the product anyway.

*the “standard” on gitcoin appears to be ETH - I have seen other tokens as the rewards, but am not sure if you can arbitrarily offer any ERC20 token, or whether they need to be approved by someone first

Thanks for the feedback @greypixel.

I’m not opposed to the idea of hosting bounties on gitcoin. The 10% cut on the bounty isn’t great… but not insurmountable. It’s worth considering indeed.

I think if we are going to update the website/create a web app (AIP30) then perhaps we can include a bounty page within that development cycle. Of course that is dependent that AIP30 passes vote. :slight_smile:

I think if we host the bounties on our own platform/website first we can give our community members priority to the bounties. If no satisfactory candidate can be found within the community to fulfill the bounty then we should have the option to host the bounty externally (on gitcoin) and open the eligibility to non-stakers.

EDIT: Please note a lot of discussion has happened in discord since this post - see here onwards - I don’t have time to summarise it right now!

Apologies in advance, this is a long post, but I have been thinking about this further, and have a few questions / concerns about the process that should probably be considered up front.

Applicant selection

It’s likely that many bounties will have lots of potential applicants, and it may not always be clear who is the best person for the job. I think it’s very important to discuss selection mechanisms before approving this.

Some of the options I can think of (feel free to contribute others):

  1. Short ‘application’ / pitch followed by community vote
    This would see candidates writing a (word-limited?) proposal covering their approach, and any credentials/experience they feel is relevant, then the community vote on who should implement after an application period.
    - Pros: Democratic & “fair”. Not ambiguous.
    - Cons: Favours people who can “sell themselves”, may penalise people who are not willing to reveal past work / prefer to remain anonymous. Slower & more voting involved.
  2. Competitive
    Anyone can work on bounties and instead of submitting proposals to work, the finished solutions are presented at the end of a fixed implementation timeframe, and the community votes to accept one.
    - Pros: Fast path to getting the “best” solution.
    - Cons: Many people will work for nothing, will demoralise more people than it satisfies. Some of the best candidates will not apply due to risk.
  3. Random selection or round robin
    • Pros: Hard to argue with!
    • Cons: Unlikely to produce best outcome
  4. Something based on length of time staking a threshold value of AST.
    • Pros: Rewards & encourages loyalty
    • Cons: Insular & cliquey

I personally prefer approach 1 out of these. I would only vote for 2 if there was some (fair) compensation for those who produced work that wasn’t used, which would be more expensive.


At some stage bounties are going to be assigned to someone who is either unable to deliver within a reasonable timescale, or who delivers to a low standard. As a result I feel we need to determine how best to not pay the full bounty amount in these circumstances. I suggest keeping it simple, and having a single vote at the end to determine the payout from the initial pot, something like: 0%, 20%, 75%, 100%. Could maybe even add a 110% for exceptional work. Clear guidance that is as objective as possible should be provided as to how to vote.

Bounty size

Who determines this? Is this another vote?

Finder’s fees

Perhaps this is controversial, but I think a 10% finder’s fee will be excessive in many cases, and may cause a lot of admin overhead as people rush to try to create bounties that end up being of a low quality so that they can claim to be the “finder”. Maybe we simply ask the person who earns the bounty whether they would like to contribute any of it to anyone involved in the bounty specification, considering the work and quality of the bounty spec.

Admin overhead

All of the above creates a lot of admin, and potentially a lot of voting. Perhaps voting on bounties should contribute a fixed (low) number of points - afterall those voting are contributing to the health of Airswap, and the effort involved for many many actually be more than voting on an AIP (multiple votes, reviewing/testing solutions)?

A different approach?

Given all of the above considerations, I think it’s also worth considering a completely different approach. Perhaps each cycle, a pool of rewards is available for non AIP activities that have been performed by the community.

Before the end of the cycle, a list can be compiled, community members can nominate others, or self nominate, and explain what has been done and what effort has been involved. Each person who voted in the last cycle can be allocated 3 reward tokens*, that they can assign to the activities (in whatever way they wish, e.g. all 3 could go to one piece of work, or they can split 1-1-1, etc).

The proportion of tokens assigned would determine the share of the community activity reward pool.

*I was initially thinking this would be fixed independent of number of tokens staked etc, but this could cause issues with sybil attacks? Suggestions welcome on this.

1 Like

Great job with the revised proposal, I really like it! When I looked at this yesterday and thought about details, I felt it was all getting over-complicated (something to which my post above most certainly will have contributed!).

This approach is simple and open, and distinguishing guided, creative activities from more specific and well defined ones (which should be AIPs) is definitely the way forward with this.

Thanks for the feedback @greypixel :slight_smile: It’s very much appreciated. I want you to know that we read your comments last night - as well some of the others - and used some of the points to debate and refine the AIP to the version that its currently in.

You are correct that simplicity is a key factor we tried to keep in this proposal - and it was initially a bit of a struggle. I think we as a team had a ‘lightbulb moment’ when we realized we could sort of change the bounty system from a ‘push’ to a ‘pull’ - ‘Request for Creativity’ format - which I think is a pretty fair and elegant solution.


@don to change status to accepted/implemented