Thales/snx grant

[Draeieg]

GitHub Sports

Using Thales and their already existing betting infrastructure from overnight markets we can increase the amount of options developers have and to earn from and give traditional non tech users access to web3 biggest sport. Development

Betting Formats

• How much time will this bounty take?

  In this format Developers can bet on how long an individual bounty will take, effectively turning the developer community into an oracle where the estimated time will be a weighed average

  This will take into account 2 factors
  1) Developer reputation or ELO, the more bounties done in time or less the Higher
  2)Bettor ELO, the more bounties correctly guessed the bigger the ELO

  This creates the following scenarios

• Good ELO hunter does Bounty in a bit less time than than estimated

  This probably means the hunter is good/has solved similar issues in the past allowing him to solve this quickly and the time estimate was correct

  • This leads to an ELO increase for the hunter and he gets the extra money from completing the bounty earlier as his incentive
  • The bettors who estimated improperly get rekt and the money gets distributed to the ones who did estimate correctly
  • The ELO of the Bettors gets affected accordingly
  • we can study the possibility of the house (us) getting a cut from the betting pool to cover our "losses" caused by paying extra to the hunter

• Good ELO hunter does Bounty in More time than than estimated but not excessive (like a 1 week estimate took 1.5 weeks or something)

  This Probably means despite the hunter being a good dev he didn't get there in time due to the time given was unrealistic

  • The ELO of the hunter remains the same (increasing elo would mean giving good hunters incentives to being late)
  • Bettors who estimated improperly get sligly rekt and the money gets distributed to the ones who did estimate correctly (the time the good dev took)
  • The ELO of the Bettors gets affected accordingly
  • The money that was destined for the "house" in the above case goes to the hunter to cover him getting underpaid (this can lead to disproportionate comp compared to what he would've gotten incentivizing good hunters to "hunt" unreasonable timelines
  • in this scenario if its obvious the hunter didn't perform as expected and tried to exploit this rule he gets treated like the case below

• Good ELO hunter does Bounty in a lot More time than than estimated (1 week bounty took >2 weeks)

  This Probably means despite the hunter being a good dev he got lazy

  • The ELO of the hunter drops a lot
  • Bettors who estimated closer to the grace period get the most money
  • The ELO of the Bettors gets affected accordingly with the monetary rewards
  • House gets a small cut

• Good ELO hunter does Bounty in a lot less time than than estimated

  This means the timeline was a bit generous or the hunter is just too good, doesnt seem fair to punish people too hard in this scenario

  • This leads to an bigger ELO increase for the hunter and he gets the extra money from completing the bounty earlier as his incentive
  • The bettors who estimated improperly get rekt and the money gets distributed to the ones who did estimate correctly but a small amount less than expected
  • The ELO of the Bettors gets affected accordingly
  • house takes a smaller/No cut that and more money is given to the hunter

• Bad ELO hunter does Bounty in considerably less time than than estimated

  This probably means the estimated time was so overkill a bad developer managed to beat it

  • This leads to an big ELO increase for the hunter and he gets the extra money from completing the bounty earlier as his incentive
  • The bettors who estimated improperly get rekt and the money gets and the ones who did estimate correctly smaller portion (bets ticks earlier can be given more money as that would be closer to the real time)
  • The ELO of the Bettors gets affected accordingly in a harsher way
  • House takes a bigger cut

• Bad ELO hunter does Bounty by a bit less less time than than estimated

  This probably means the estimated time was so overkill a bad developer managed to beat it

  • This leads to an ELO increase for the hunter and he gets the extra money from completing the bounty earlier as his incentive
  • The bettors who estimated improperly get rekt and the money gets and the ones who did estimate correctly smaller portion (bets a few ticks earlier can be given more money as that would be closer to the real time)
  • The ELO of the Bettors gets affected accordingly in a harsher way
  • House cut up by a small margin

• Bad ELO hunter does Bounty in more time than than estimated but not way more

  This probably means the estimate was accurate

  • ELO of the hunter drops
  • bettors get their money and ELO as expected
  • house gets a smaller cut

• Bad ELO hunter does Bounty in way more time than than estimated

  This probably means the estimate was a bit unrealistic because even someone "bad" didn't manage to get there in time

  • ELO of the hunter drops
  • bettors get their money and ELO as expected with rewards skewed at the longer end
  • house gets the normal cut

• any ELO hunter completes the bounty in the expected Time

  estimate was accurate

  • ELO of the hunter increases
  • Bettor get the expected amount of money/ELO
  • House takes its cut

General Reasoning/Potential issues/Random things

1. Implement the "tennis game logic" between bettors and hunters
2. Reward good hunters with perks like the essential "grace period" they get but also punishing them way harsher for doing a bad job to prevent resting on laurels
3. Having bad ELO can be dodge by just making another account so it will probably be a bad idea but its a starting point
4. we will need data to get the correct standard deviation to calculate things like "this one was off for like 2-3 days"
5. punish bettors for overpaying/giving too much time and incentivize reputable hunters to find rushed and unrealistic deadlines
6. House cuts mean extra revenue source to help make the devpool itself free of fees for partners

Gauntlet style bets (essentially a normal sports tournament parley

Another Popular type of bounty is the "free for all" where developers (or teams) compete for the best solution to a problem, in this scenario people can bet on who will win, this format has the advantage that normal people can participate as the track record of hunters can be used to bet on who will win

This format con be extended to a full style sports tournamet where we do either bracket style matches or publish a set of free for alls and people can bet on who will win in batches

example of additional formats available for eveyone

1. bet on who will be at the top of the leatherboard
2. bet on who will complete the most bounties
3. bet on who will have claimed the most amount of money
4. bet on who will the biggest perfect streak//less time than expected

[0x4007]

I think that we should first focus on launching an ultra simple version of this (more complicated is also not necessarily good, as it will take a lot more effort for marketing to educate users on what the product is, and how to use it.) We also currently do not have reputation support. This is planned for v1 if I recall correctly, which means we will need at least 3-6 months before we can get to it.

The ultra simple idea being that we let all the active bounty hunters (perhaps you must have collected at least one bounty) bet a time estimate per bounty. The objectives are:

1. to crowdsource information on how long the task should take, signaling to the bounty creator what is a reasonable time to set (thereby also affecting the bounty's price.)
2. financially incentivizing the community to vote accurately.

Financial Incentives

• Inspired a bit by Chainlink's oracle architecture, we can have voters stake some asset (in the context of this grant, it would be sUSD?) to "back" their vote.
• Because the voting information is public, risk could be perceived as half with every subsequent vote. This means that rewards should potentially also halve from subsequent votes.
  • This could be implemented by making the first vote minimum stake X amount (configurable) for example: 100 sUSD, the following vote 50 sUSD, next 25 sUSD etc.
• We could end the betting if there are no more votes for 24 (configurable) hours, or if the bounty creator forcefully ends it.
• Winner is consensus between the median vote AND the bounty creator.
  • If there is a disagreement with the median and bounty creator, everybody gets their money back. This is to serve as a protective measure for when the crowd tries to game the bounty creator with obviously bad information. Like a sybil attack with "15 minute bounty" votes when the task is expected to take a week.
  • If the bounty creator agrees with the median, then the further one's bet is from the median, the more slashed they are.

Voting User Interface

To reduce chattiness of the GitHub Issue conversation, we will need the bot to either add a comment right after a specification is created, or edit the original comment (the bounty specification comment) and append custom buttons (links) that will allow voters to vote on the issue.

• As soon as a vote is made, the bot can update the comment to show the live voting stats.
• The vote deadline should be displayed.
• We could consider a vertical bar chart to concisely show the median (the tallest bar) and how many users voted on which.
• We need to figure out a way to authenticate the votes. This can be done with the user's GitHub ID somehow, or by signing the vote message using their registered wallet address.

These estimates can be quantized to pre-defined increments (example increments below, but these are subject to change - less is better) in order to increase the probability of a confident median.

Weeks	Days	Hours	Minutes
			15
			30
		1
		2
		4
		8
	1
	2
	3
	4
	5
1
2
3
4

Bootstrapping Activity

The rewards are distributed from losers to winners. If there are not many participants, it could be a waste of time. We should allow bounty creators to add sUSD as a participation reward. This will allow them to effectively pay for the voting service, possibly saving themselves the time to research and figure out the correct answer. This reduces risk from the voter's perspective of having had wasted time.

Remarks

I have concerns on the different opinions of novice to experienced developers. Novice developers may have a tendency to always go above the median, where the experienced developers may go below. I am debating on averaging the results vs using median.

Average will reflect the opinions of the entire community more accurately. Whereas the median will reflect the most common vote. This is arguably more democratic but this may be overrepresented by the novice and intermediate devs, as I assume there may be more interest from these demographics.

Perhaps we should just use averages.