The Piccadilly Circus Games have now finished.

You are viewing an archive of the Piccadilly Circus Games Competition. Join our Discord for the latest information.

Bug Bounty

Find and report bugs to win points. The top 20 bug finders in Round #4 win an award. At the end of the Games a roulette selects 5 bug finders who were not winners in a round, and those 5 win an award as well.

Synopsis

You compete in this challenge by submitting valid bugs against Autonity code and documentation. One bug submission can be made per issue raised against any of the five eligible projects:

Bugs can be submitted at any point between the start time of the Games and the end time of the final Game Round #6. Bugs submitted outside of this period will not be considered. But it’s fine to submit bug reports between game rounds; they will simply be counted in the next round.

In this game task, the term bugs really means issues. There are three types of “bugs” that are eligible for this task:

BUGS: issues that an eligible project’s code owner(s) agree should have the bug label in github.
INTEGRATION: issues with integrating the eligible projects, or integrating an eligible project with other EVM ecosystem tooling that the eligible project’s code owner(s) agree should lead to a change in the eligible project’s code.
DOCUMENTATION: issues or improvements to documentation of the eligible projects. Documentation refers to docs.autonity.org and repo readme’s and command --help messages of all eligible projects.

How to enter

How to submit issues to Bug Bounty

Ready to take part? Complete the Games Registration Form if you haven’t done so already.

Bug Bounty entries are submitted in a 2-step process:

Raise – Create GitHub issue in one of eligible projects repositories. Follow the project’s conventions for raising issues as you would if you were not doing this as part of the Games.
- unless the issue is security critical, in which case do not raise a GitHub issue and follow the instructions in SECURITY.md instead.
Submit – Use the Report a bug Form to submit the above issue to the Games.

Submissions are triaged by a community panel made up of the Autonity core development team. Points are earned for submissions that are considered valid bugs. Submissions reporting issues that have been already raised in an eligible project repository or otherwise publicly known by the project’s maintainers (e.g. on a Known Issues page) will not be considered valid bugs.

Awards

Round #4

The Bug Bounty challenge for Round #4 has an award pool of 20,000 Award Tributes.

Scoring rule parameters for the task are set as:

\(N_{fb}\)	\(N_{max}\)	\(R\)
`10`	`20`	`95%`

Where:

\(N_{fb}\): the minimum number of task participants below which a partial distribution of the reward allocation takes place,
\(N_{max}\): the maximum number of winners for the task,
\(R\): the significant participant threshold for the task.

Winners are ranked by scoreboard position. In the case that participation is higher than \(N_{max}\), the top scoring participants up to \(N_{max}\) will be chosen as winners.

Roulette

If you don’t make it into the winners for the round, you still have a chance to win an award through the Roulette, so you should always submit your bugs!

The roulette is run at the end of the Game’s Final Round #6 and randomly selects 5 bug submitters who have not been a bug bounty winner in any of the game rounds. 5 roulette winners are chosen, winning 1,000 Award Tributes each.

Scoring rule

Round #4 scores Bug Bounty individually using a methodology based on:

an award pool of a fixed amount for a task
a floor and ceiling for participation and winner numbers to calculate winner award allocations:
- a significance threshold \(R\) of 95%. The top ranked users that accumulate 95% or more of the total score for the task are eligible. This puts a minimum score floor on the task.
- a minimum number of participants below which a partial distribution of the reward allocation takes place - \(N_{fb}\)
- a maximum number of winners for the task - \(N_{max}\)
points are scored for task completion by stated scoring criteria
winners are ranked by scoreboard position. In the case that participation is higher than \(N_{max}\), the top scoring participants up to \(N_{max}\) will be chosen as winners.
task participation must be significant. Only significantly scoring participants are counted - i.e. the top ranked users that have accumulated the \(R\) of 95% or more of the total score
awards from the pool are distributed to the winners. Each winner’s award amount is calculated according to their score and the total number of winners.

The significance threshold puts a minimum score floor on the task. Scores must be in the \(R\) top 95 percentile to be eligible for an award.

The \(N_{fb}\) floor allows for a low participation scenario resulting in the entire award pool going to a few participants rather than the wider community. If this scenario were to happen, then the remaining reward allocation is carried forward for future incentives.

The number of points earned for bug submission depends on the type and severity of the submission, as evaluated by panel. Here is the scoring rule:

Type	Severity	Points
`DOCUMENTATION`	None	10
`BUG`	`LOW`	15
`BUG`	`MEDIUM`	25
`BUG`	`HIGH`	50
`BUG`	`CRITICAL`	100
`INTEGRATION`	None	15

Points earned for accepted bug submissions are added to a participant’s username account on the game scoreboard on the next scoreboard update after triage assessment completes. Winners based on their scoreboard position will be announced at round end with other award winners.

The task scoreboard can be viewed on the Leaderboards page.