DotHacks private SRC

[dothacks]

Grant Application Checklist

• The application-template.md has been copied, renamed ( "project_name.md") and updated.
• A BTC or Ethereum (DAI) address for the payment of the milestones is provided inside the application.
• The software of the project will be released under the Apache license version 2.0 as specified in the terms and conditions.
• The total funding amount of the project is below USD $30k for initial grant applications and $100k for follow-up grants.
• The initial PR contains only one commit (squash if needed before submitting your PR).
• The grant will only be announced once we've successfully delivered the first milestone.

[rrtti]

Hi, I have a few questions and comments regarding this proposal:

• Why are you not submitting this as a treasury proposal directly for funding to one of the networks? An extension of a current pallet in use seems like a good use case for the treasury to cover - and has happened before, with bounties extension in particular.
• Regarding the flow: The whitehat will need to bond a deposit to submit the report: am I right in understanding that, if the report is rejected, the bond will not be slashed but returned? How do you propose to handle malicious behaviour by whitehats? and could you point out how is the bond calculated in the pallet?
• Regarding thesend_rewards call: is this call executed by the Council? wouldn't it be better to experiment with a new collective composed by all curators in which they can vote for this call in an autonomous way? do you think a curator collective might work? I'd love to hear your opinion on this.
• what about UI development? any plans there from the team? Does Dothacks have plans to work on this as well?
• I would appreciate if a change of name is discussed for this extension: something from "Bug bounty" to "SRC Spendings" or something similar could work. This change would avoid any confusion with the current pallet. I know the bounty extension in place now should have been renamed and there was some discussion about this in the past, but given its history, id like to leave it as it is for now.

Thank you.

[dothacks]

Thanks for your reply：

• As a start-up team, our original intention was to use the open grant opportunity to start our DotHacks idea while creating value to Polkadot. We also hope the collaboration can be more continuous, such as to continuously build our platform on Polkadot ecosystem and get a follow-up grant. On this basis, we are pleasure to embrace any kind of collaboration.

• Rejection of vulnerability report include situations caused by non-malicious reasons, in these cases, the deposit should be returned. For this stage, we can add a slash operation in addition to the acceptance and rejection operation, so that the curator will be responsible to define the malicious behavior which may cause negative consequences, and detain the deposit for punishment. For the bond amount, we noticed that the existing bounty's bond is calculated according to the description length, but report field in SRC spending instrument is only a URL of encrypted vulnerability report, so we suggest it to be fixed at the beginning. In the future plan, we will propose complete and clear standards that public to the community, including the definition of malicious behavior, and a reputation system to dynamically adjust the deposit amount. Effective standards and rules are the cornerstone of an SRC or Bug-bounty platform.

• Yes it is executed by the council in the current design. We agreed that the autonomous of a curator collective is a good idea, and the efficiency of the workflow can be improved since it is independently operated of the council. In terms of the specific design of the functions, we can separate vulnerability verification, vulnerability rating and pricing, and bounty payment. First, a randomly elected curator decrypts and verifies the details of the vulnerability to minimize the risk of leaking report details. Then, all curators will vote on the vulnerability rating and value based on the effectiveness and harmfulness. Finally the whitehat can claim the reward according to the curator voting results instead of council sending the rewards.

• Sure. We will be very happy to do the UI development as well. We will add UI related part of work into the application.

• No problem, we think that "SRC spending" will be a good name for the instrument.

[Noc2]

Thanks for the application. In general, I think we are interested in supporting this via grants. However, I have the feeling that (if possible) it would make more sense to get this funded via the treasury directly, since this will change the treasury pallet and I think the on-chain council should be aware of this. Did you already share this in the direction channel?
And a few additional comments/questions: Do you still plan to integrate additional changes to the application based on your comment above? Could you be more concrete with the deliverables and specifications in the table? These are basically the requirements of our contracts. For example currently it’s not clear that your work will be based on the Treasury pallet.

[rrtti]

@dothacklab @Noc2 Happy to jump on a call with the team to work on a proposal to be submitted for Council review - feel free to ping me on Element: @raul.rtti:matrix.parity.io

[alxs]

@dothacklab feel free to close this at any time or leave a comment if you still want to go ahead through open grants.

[dothacks]

@Noc2 Thanks for the response and recognition of our ideas.
Since it will be necessary to merge the code of the SRC spending instrument onto the substrate repo, we are happy to do the application and submit relevant code directly through treasury for this part of work. We will be appreciated for the assistance from @rrtti about the specific procedure. And thanks @rrtti again for the active support!
Regarding UI, formulation and implementation of standards and rules, or the other follow-ups, would it more appropriate to be applied in open grant? We are sincerely looking forward to the chance of collaboration between DotHacks and w3f as well.
If the thoughts above are workable, we will update the application documents and include the ideas from the last discussion by next Monday.

[dothacks]

@dothacklab feel free to close this at any time or leave a comment if you still want to go ahead through open grants.

@alxs Thanks for the reminder. At present for the SRC instrument part we decide to go through treasury directly. For UI, standards and rules, and the other follow-ups, open grant is preferred for us if it is possible to divide it into two applications. Otherwise we can apply a follow-up grant application when we finish the instrument part of work.

[Noc2]

Thanks for the response. Indeed, I think it makes sense in this case to initially apply for treasury funding and potentially a follow-up web3 grant for the UI. Once the pallet is accepted by the council we definitely have an interest in supporting the development of an (or even multiple) UI(s). Therefore, I’m closing the application for now. Let me know if I should reopen it or feel free to send us another application for the UI.

[dothacks]

Thanks for the response. Indeed, I think it makes sense in this case to initially apply for treasury funding and potentially a follow-up web3 grant for the UI. Once the pallet is accepted by the council we definitely have an interest in supporting the development of an (or even multiple) UI(s). Therefore, I’m closing the application for now. Let me know if I should reopen it or feel free to send us another application for the UI.

@Noc2 Thank you. No problem at all.