Create a contest to encourage users to test new SOVRYN features on testnet

Adoption Hive
1

This is a proposal for a bi-weekely contest, matching each sprint.

This contest suggest to offer a first prizze of 600 SOV tokens
a second prize of 300 SOV and a third prize of 200 SOV.

I, the proponent, offer as the first jury member, but it is needed at least 3 members.

Take a look of the proposal here: BI-WEEKELY CONTEST FOR TESTS REPORTS FOR SOVRYN USERS - Google Docs

8 Likes
2

Thanks a lot, Julio, for proposing this recurring contest. I think your post will get more attention if you prepend the title with ā€˜SIP 12ā€™. I like it, but maybe you could add some criteria to the proposal giving a judging guideline for the jury? To reduce arbitrariness, we could e.g have a formula giving the points of a participant depending on the number of bug reports and the severity of the reported issues. then, the jury would just need to decide on severity and which reports are valid.

Why are you proposing to let the reporters sign a message to verify their address?

I think the prizes are a bit on the high side. Youā€™re suggesting an ongoing program. So, weā€™d also need to pay these rewards even if no relevant bugs are found. Maybe the SIP should include some minimum requirements for the bounties to be paid as well?

2 Likes
3

The choice of comic sans as the font for this SIP is very bold.

Besides that I Iike the proposal. I think the rewards might be a little on the high side.

4 Likes
4

Please, check the proposal updatedā€¦

Main changes:

1.- First prize is of 120 SOV, second 60 SOV, third 40 SOV; for a monthly award of 440 SOVā€¦ If it is still too much, just comment and we can reduce it even more.
2.- This practice (requiring a signature) is expected to prevent any dispute (by that moment or in any future) between users over the ownership of any report, and give the jury a proof that the address receiving any award corresponds to the maker of the winning report. (Letā€™s remember that these award-transactions are irreversible).
3.- A score table with a criterion for the assesment of the reports was included.

5

Hi Edan, I didnt see your comment; well we should make a poll about the rewards, take a look on the additional score- table

6

This is a very important initiative, because as you explain in your proposal Sovryn is a sum of development and action. When users discover issues, they can either keep silent or make them public.

To achieve the latter requires generosity, motivation or both. Therefore, rewarding usersā€™ engagement with Sovryn may be the right strategy because recognising the value of the help helps at the same time to give value to Sovryn.

I have these questions:

  1. What is the channel for communicating bugs?
  2. What if there are several users reporting the same bugs at the same time in parallel?
  3. is there a log of reported bugs that everyone can observe to know if they were already reported and even the progress in solving them?
  4. Maybe there are ten users who have discovered bugs, but since there are three prizes, seven will not be rewarded. Maybe those seven bugs are more important together than each of the first three individually. However, they will not be rewarded.
1 Like
7

It is a very interesting question set, and it could be solved with the most important technology ever: the very blockchain.

This additional solution could be added as part of the proposal: the user can create a report, get the hash value of the report, and send a transaction with the hash of thier report in the data field. Even a smart contract is not required!.. look at this testnet transaction I did to myself with the data 0xc3e24ffb055674ff4c3a053a57386262d25846d988151e887acb48652483d440 :

https://explorer.testnet.rsk.co/tx/0xd20a17488e74d7174f6ddc0bb76d54c727002b8d9b09107b7cbd61f416f5f9a8

The order in which the reports are confirmed in the blockchain may solve the potential dispute over who was the first on what, then each user without rush can file the original report to a jury channel in discord, toghether whit the transaction with the proof of author rights of the report; and then the jury will evaluate each report deciding for a winner.

The signature would no longer be needed coz, the user already had to sign the transaction to file his report.

An idea to develope a little bit more and then to include in the proper SIP. I hope other members on the forum can check these mad ideas.

As regarding your question NĀ°4, the winner reports should be the most useful ones, so the winner reports are expected to gather the largest amount of bugs in them.

Sadly if there are allowed more than 3 prizes, the proces turns too complicated.

2 Likes
8

i agree this would be a good SIP. maybe @light can assist in standardizing it!

2 Likes
9

I understand what you are explaining.

Maybe the system can exercise a natural selection of the best bug hunters. Surely it is important to be practical.

Letā€™s look at other opinions from other forum membersā€¦

Thank you!

1 Like
10

I think thereā€™s a really good proposal in the making here, good job @juliomorosā€¦ Forgive my ignorance but how long are the Sovryn sprints (makes a difference in assessing how reasonable the prizes are)?

My only suggestion is to consider a small additional prize, determined by a lottery of all addresses that submitted a report of sufficient quality (there would need to be a minimum number of entries and the lottery canā€™t be won by those already claiming a prize)ā€¦ Just think thereā€™s value in providing a small incentive to those who look but donā€™t necessarily find.

1 Like
11

A sprint last two weeksā€¦ The lottery would imply a smart contract to be developedā€¦ And an additional budget, perhaps for a version NĀ° 2 of this proposal.

1 Like
12

I love it! thank you for giving us another opportunity team!!

13

Well I think is time to be preparing the formal SIPā€¦ wish me luck! :nerd_face:

3 Likes
14

i think the sip should include a link to the discord channel #user-feedback or #bounties for reporting

1 Like
15

A branch for this proposal has been created. I hope to receive some comments (SIP in the DRAFT Stage)

The proposal is this:

16

The amount of work to be done by the jurors will climb into hours if not dozens of hours per month as time goes on, it will be hard to motivate the jurors to properly do the due diligence the check every report, then criticize the bug report, score every aspect of the bug report, check if the user signed a message, then talk to the other jurors and once you finally come to a conclusion you have to sign a multisig to send the bounty.

Point is that you are asking alot from these jurors for what is basically volunteer work, and at that you are giving 3 people the power to distribute 440 SOV a month (currently around 2k usd). If they are not financially incentivized, collusion might be an issue.

17

I agree with you that should be there an incentive for jurors; and the common answer Iā€™ve received from most of the people Iā€™ve asked in private to be one of them is that they are too busyā€¦ We are all supposed to be very busy, and this extra activity as jurors, is outside our duties within Sovryn day-by-day work.

By the other hand, I know the Sovryn team, and all of us are amazingā€¦ (my personal opinion), and I think all of us love our work, and the reason why we are here, and I see a collution as something very unlikely; however, the extra effort it would take should be incentivized; as @yago mentioned in the last community call here: https://youtu.be/X7_rqBdAQIo?t=2719

I may suggest to award each jury member with 100 SOV tokens per month, for a total of 300 SOV tokens per month for jury members.

Another important thing is to make this a proposal just for 1 quarter; e.g. from April the 1st to June the 30th. Things in Sovryn are changins too fast as to pretent set a monthly undefinite program like this.

Iā€™d like to see some comments before include these changes in the SIP-0013 draft. Thank you very much.

2 Likes
18

Disclosure: @juliomoros asked me to be one of the jurors, and these are the questions i raised which he suggested i post to the forum for consideration by others:

  1. There DOES seem to be quite a bit of focus on form and process, are you sure youā€™re not going a bit overboard? Could this be simplified to decrease the workload, as mentioned by sway? Regardless of compensation incentives, this could really be a lot of work that could create conflicting priorities in a jurorā€™s responsibilities.

    • how many bug bounty reports do you estimate receiving realistically per sprint?
    • could we combine the process to only happen every second sprint, but combine the sprints in the judging?

  2. are you SURE that we are better running a bug bounty program ourselves rather than using gitcoin?

    • i guess an argument for running a testnet bounty contest is that we identify bugs and inconsistencies in the UI / UX earlier, and identify exploits earlier saving the project time and money when itā€™s a mainnet deploy, but why would we use such a program, if in place, only for testnet?
    • One of the things you mention is using the BBP as a hiring pipeline for obviously talented people, and indeed, that has bounty programs have proven to be one of the best ways for onboarding talent in the cryptosphere, which makes me think that your proposal would best be serve sovryn by being expanded in scope, rather than minimized to a single aspect of our products / code.
    • @yago reached out to @stefan regarding using gitcoin as a hiring pipeline last week, who reached out to me. The thing about running bounties over gitcoin is that it needs someone dedicated to managing the user account, process, content, as well as promoting itā€™s existence on social media channels etc to get traction and attention. Just ā€œhavingā€ bounties doesnā€™t mean they get looked at - even here one faces competition for available resources and attention.

So, when i see your dedication to (and the quality of) this proposal, iā€™m starting to think that it should be expanded in scope and budget, and run over gitcoin as a monthly program incorporating the two sprints

Would you be willing to be responsible for this, if we did so? Would you have the TIME to do so amongst your other responsibilities for Sovryn?

Take a look at the gitcoin process here: Quickstart | Gitcoin , b/c it covers all of the necessary steps weā€™d have to duplicate for an internal program.

3 Likes
19
  1. Running an inhouse test-net bounty program is a project in itself that needs a dedicated team to analyse any incoming reports. Nevertheless, it highly desirable to have one such program running in order to prevent any errors that might affect the project reputation
  2. It makes more sense to award the prizes on a monthly basis. Firstly, that is a standard promotion structure used in various industries across the board and, secondly, it is easier to manage it from the operational perspective. In order to sweeten the deal, the prize structure can be expanded to 6 monthly rewards.
  3. I would not market such a ā€œcompetitionā€ as a permanent one right from the start. I would rather announce it to last for a couple of months and reconsider it further down the line.
  4. Gitcoin is a platform that might make the entire process easier for the reviewing team. Also, that will facilitate the program expansion to all bugs categories. But, that needs an active and tech-savvy admin.
20

Definitely agree with this proposal. Regular public testing should be encouraged and incentivised. I like the revised reward amounts but agree with other comments that there should be a scoring system, with a minimum threshold to pass eligibility for a reward.
Whether this is the right approach or not, I believe there should be some sort of test system in place going forward.

As for the comic sans. I would like to suggest a separate proposal SIP to make all of Sovryn use comic sans from now on.

2 Likes