Introduce Korporatio extension

[kronosapiens]

Closes #1118

Current flow:

• Users can stake to create applications using submitApplication
• Admin or root users can stake for free using submitFreeApplication
• Users can cancel their stake using cancelApplication
• Users can reclaim their stake after cancelling, once the claim delay has elapsed, using reclaimStake
• Arbitration users can slash a stake, using slashStake, optionally slashing reputation
• Users can update the IPFS hash of the application using updateApplication
• Root users can submit the application (emitting an event) and cancel the stake, using submitApplication
• Architecture users can update the stakeFraction and claimDelay values using the respective setter functions

The intention is that the claim delay allows for the colony to punish an applicant for malicious behavior, and that the final submission of the application take place via a motion. Updating the IPFS hash emits an event, which can be used by the Dapp to render the UI.

[kronosapiens]

@arrenv @area take a look and let me know what you think. I tried to provide functionality to support both the centralized and decentralized use cases.

@arrenv could I have more clarification on what you intend for paying for the application. Would that be a motion that transfers funds to... the metacolony?

[arrenv]

@arrenv @area take a look and let me know what you think. I tried to provide functionality to support both the centralized and decentralized use cases.

@arrenv could I have more clarification on what you intend for paying for the application. Would that be a motion that transfers funds to... the metacolony?

Sorry for missing this until now.

Question, is the claim delay configurable? Can the claim not just be returned with the cancellation? Also, this would likely require additional UI, right?

Payment for the application will be done using a Motion, I feel the best implementation of this is for the payment to go to the MetaColony. However, the original intention was to have it go to a hard-coded address directly to the incorporation service provider. Do you have any opinions on this from a contract perspective?

[kronosapiens]

@arrenv the claim delay is configurable. The idea is that if a user cancels the application, there is still time to slash the stake in the case that a user is malicious. If they could immediately cancel and reclaim their stake, then there would be no way to slash them.

My suggestion would be for a function on the extension to take the funds (as part of the submit function) and transfer them to the metacolony. That way the motion is a single function call to the extension. The extension could allow the application fee to be configured by the colony, or it can be hard-coded. Up to you. Normally I would be against hard-coding but I could see the value in this case.

Also, I'm assuming the application fee should be paid in CLNY? Or xDAI?

[arrenv]

@kronosapiens What would be the downside of them cancelling it themselves straight away? What impact would have have on the Colony as a bad actor?

Not saying we shouldn't have it, but I am curious as to the importance of it. It is also something we will need to account for in the UI.

I do prefer the payment to be made into the Metacolony being the flow. The downside of it though is that it then becomes an issue of tracking/reconciling that payment and then manually processing it to be sent to the incorporation service provider.

The application fee is currently denominated in USDC.

[kronosapiens]

@arrenv see here: https://github.com/JoinColony/colonyNetwork/issues/1118#issuecomment-1424856421

[arrenv]

@arrenv see here: #1118 (comment)

Thank you, I recall it now. I will make a note of it for the UI updates.

[kronosapiens]

Noting that @area is asking for a test showing that stakes can be returned to a user if the extension is deleted

[kronosapiens]

@area @arrenv this is ready again, with tests added showing the desired behavior. The information regarding the application fee has been removed, with the understanding that colonies will send the fee to the MC separately.

[kronosapiens]

@area the slashStake function allows an application to be cancelled with a motion. This also slashes the user's stake. The scenario where a colony would want to cancel a motion but not slash the stake seems unnecessary to me.

Regarding the editing of the motion, I made the argument that such backs-and-forth can occur off-chain, and the applicant can update the IPFS hash as needed. I suppose we could allow updateApplication to be called via a root motion, if that is important.

@arrenv thoughts on these?

[arrenv]

@area the slashStake function allows an application to be cancelled with a motion. This also slashes the user's stake. The scenario where a colony would want to cancel a motion but not slash the stake seems unnecessary to me.

It would still be necessary to cancel an application and have the option not to slash a stake. An example scenario of this is that it has been decided to delay the application to a date in the future, and the application was not created in malice.

Shown in the design with the force toggle, and the option to show mercy:

Regarding the editing of the motion, I made the argument that such backs-and-forth can occur off-chain, and the applicant can update the IPFS hash as needed. I suppose we could allow updateApplication to be called via a root motion, if that is important.

It would allow more flexibility to allow people other then the applicant to make changes via a motion, otherwise full control of the application itself remains with a single person. Editing via a motion is how it was spec'd and designed for this reason.

[kronosapiens]

@arrenv currently you can "show mercy" by not penalizing their reputation. Are you saying that "showing mercy" would be not slashing tokens OR penalizing reputation? Should those be two different options, or should they always come together, i.e. either you slash both tokens and rep or neither?

[arrenv]

@arrenv currently you can "show mercy" by not penalizing their reputation. Are you saying that "showing mercy" would be not slashing tokens OR penalizing reputation? Should those be two different options, or should they always come together, i.e. either you slash both tokens and rep or neither?

Yes, I think it would be better to just keep them as one as you said. I.e. 'Smite' would slash both both tokens and rep, 'Show mercy' would not slash both tokens and rep.

[kronosapiens]

I've updated the PR to allow for applications to be updated either by the creator or via a motion, as well as the other changes we've discussed.