Rfp/security marketplace

[ParthChaudhary31]

Project Abstract

Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs).

If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or BTC, Ethereum (USDC/DAI) or Polkadot/Kusama (USDT) address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[CLAassistant]

All committers have signed the CLA.

[keeganquigley]

Thanks @ParthChaudhary31 you mentioned that this would help save on development costs, does this mean there should be an adjustment in price as well? Or are these only contract deployment costs that aren't covered as part of the grant?

[ParthChaudhary31]

Thanks @ParthChaudhary31 you mentioned that this would help save on development costs, does this mean there should be an adjustment in price as well? Or are these only contract deployment costs that aren't covered as part of the grant?

The latter actually, The cost-cutting would be on the front of :

1. Deployment costs (Contract optimization by merging functionality into a single contract would require deploying fewer contracts).
2. The Arbiters will not need to spend from their own pockets while voting. (Minimising gas fees Charges).

[keeganquigley]

Thanks for clarifying @ParthChaudhary31 LGTM

[semuelle]

Deployment costs (Contract optimization by merging functionality into a single contract would require deploying fewer contracts).
The Arbiters will not need to spend from their own pockets while voting. (Minimising gas fees Charges).

I think that (a) deployment costs are negligible as this is a small, one-off fee; (b) combining the contracts makes them less general and reusable, and (c) having an on-chain record of arbiters' voting would make the whole system more trustworthy. The cost of voting is also rather small and there are other ways this could be limited, e.g. by fee-less transactions or a reward pool.

(a) and (b) aren't showstoppers, but I'd be in favor of keeping a trace of the arbiters' votes on-chain.

[ParthChaudhary31]

@semuelle ,
I understand your motives for keeping the Arbiter voting on-chain, The change is a suggestion that we believe would smoothen the onboarding process and encourage arbiters, however, we're perfectly fine with keeping it on-chain as well. If you can verify with the remaining team and give a final verdict on the changes, We'll be able to plan accordingly and start with the development.

[semuelle]

Thanks, @ParthChaudhary31. Sounds good to me. Could you integrate this into the document? I will ping the rest of the committee again.

[ParthChaudhary31]

@semuelle
Sure, I've re-added the Arbiter's voting contract to milestone 1, We'll start working on it now and aim to finish this soon.

[semuelle]

Thanks.