Extension required for incorporation feature

[arrenv]

Prerequisites

The incorporation feature will provide an important solution to a lot of DAO projects, allowing them to create a legal wrapper around the DAO. This would enable the DAO to operate in a legal capacity and help to protect it's contributors. This is an important feature to include within Colony as the governance mechanisms are useful as a decentralized way in which to first create the legal wrapper and then to also decide what is required to be ratified by the legal wrapper.

Description

In order to implement this feature, it is necessary to create an extension to help facilitate the staking requirement. The intention of the staking requirement is a means of spam reduction and protection for the Colony, deterring non-serious applications and allowing a mechanism to punish those that start the incorporation process as a bad actor.

The process itself should allow collective input on the application, however, the staker will remain the owner of the application given their stake. Once consensus has been achieved, the owner can create a motion to fund the application. Once funded, the application will be sent for processing.

Acceptance Criteria

• Allow a user to stake in order to be able to start the incorporation process.
• The required stake amount should be derived using the same calculation as motions do, i.e. using reputation in the root domain.
• The user who stakes will be the owner of the application
• With the root or administration permissions, the user can skip the staking requirement.
• The owner should be able to edit the details of the application at any time.
• Anyone else can make change requests to the application, but changes will require a motion.
  • I'm wary that this likely requires the details of the application to be stored on chain, although in a general sense, I don't feel it is necessary to store the application details on chain in order for a motion to be able to update details.
  • I'm happy to consider other ways of approaching this. If it proves unsuitable we may be able to consider limiting changing the application details to the owner only.
• The owner can trigger a motion to make the payment at any time.
• Be able to cancel a staked application with a motion.
• For a cancelled application, be able to decide if the owner should be penalised or not.

[EDIT] This has been overlooked, but is a required for full acceptance.

• We need to be able to release the stake on completion of the application.
  • Needs to be it's own address used specifically for this action without needing a Motion.
• We need to ability for the incorporation agency to be able to cancel applications.
  • The default for this would be to not punish.
  • Needs to be it's own address used specifically for this action without needing a Motion.
• We need to be able to toggle between a locked and unlocked state to there is not a race condition and applications cannot be changed after they have been submitted, but need to be returned to an unlocked state to allow updates that are required after feedback from the registration agent.
  • Needs to be it's own address used specifically for this action without needing a Motion.
• There needs to be a way to be able to attach the payment of the application made through a Motion to the specific application.

Design

• Figma link: Start of the full process

• Figma link: Design of the staking modal

[kronosapiens]

@arrenv as I start to work through this, one idea I had would be to introduce a "cooldown window" after the applicant cancels their application and before their stake can be reclaimed. This would allow a colony to make a motion to slash their stake, while avoiding a lot of complicated controls around when a user could cancel their application.

[arrenv]

@arrenv as I start to work through this, one idea I had would be to introduce a "cooldown window" after the applicant cancels their application and before their stake can be reclaimed. This would allow a colony to make a motion to slash their stake, while avoiding a lot of complicated controls around when a user could cancel their application.

I think that is a good idea, nice one!

[area]

I don't feel it is necessary to store the application details on chain in order for a motion to be able to update details.

Can you expand on this? How do I know what I'm voting on if they're are not stored, or at least referenced, on chain?

[arrenv]

I don't feel it is necessary to store the application details on chain in order for a motion to be able to update details.

Can you expand on this? How do I know what I'm voting on if they're are not stored, or at least referenced, on chain?

When a Motion is created for the payment, then the details will need to be on chain. I was thinking that prior to this though you could get away with not having to store details on chain while they are still being decided.

[kronosapiens]

@arrenv was talking to @area today and he was wondering how this functionality will look for a decentralized user of the dapp. Specifically, user A puts in a stake to access the incorporation flow, with an application stored on the server. User B is using a decentralized version of the dapp -- will they not be able to see the application? Not see it until the motion has been made? How will the experience translate between centralized and decentralized versions?

[arrenv]

I'm not 100% sure how it will be implemented from a technical standpoint, but I am assuming it could be stored in IPFS until the application details are ready to be ratified onchain with the payment request motion. Which would make the experience the same for both versions.

[kronosapiens]

Following up, perhaps the dapp would show any application data stored on IPFS, and reference the extension to decide which apps to render in the UI.

[kronosapiens]

As an update, my thought in approaching this has been to develop a more generic UxGate extension which can be used to implement staking to allow access to various UI features. It would accept a stakeType argument which in this case would be Korporatio or something similar, but could be used for other things. My justification is that there is very little in the contracts that is Korporatio-specific, but seems to be more concerned with using stakes to manage access to UI more broadly.

Update: whether that is a per-stake value, or a configuration parameter for the extension as a whole, is up for discussion.

[arrenv]

As an update, my thought in approaching this has been to develop a more generic UxGate extension which can be used to implement staking to allow access to various UI features. It would accept a stakeType argument which in this case would be Korporatio or something similar, but could be used for other things. My justification is that there is very little in the contracts that is Korporatio-specific, but seems to be more concerned with using stakes to manage access to UI more broadly.

Update: whether that is a per-stake value, or a configuration parameter for the extension as a whole, is up for discussion.

I certainly like the idea of a more generic extension for this. It would certainly allow for more flexibility with the same sort of flow in the future.

I feel that given an implementation as a generic extension, it would make sense to make this a configurable parameter. It would give a lot more control for a DAO. It would still be important to have an option that uses the same staking calculation as Motions though, i.e. "Required stake based on individual user's reputation".

[kronosapiens]

@arrenv when slashing a stake, would you like to be able to decide whether or not to remove reputation, as well as the stake? I'm thinking of a logic similar to what we do with stake expenditures.

[arrenv]

@arrenv when slashing a stake, would you like to be able to decide whether or not to remove reputation, as well as the stake? I'm thinking of a logic similar to what we do with stake expenditures.

Yes, let's follow the same logic as staking expenditures.

To confirm though, when slashing on an expenditure, in the designs you are choosing to slash or not. There is not a separate one for slashing reputation or not.

However, is that how it works on the contracts? I.e. you can choose to both slash stake and reputation or whatever combination of those two options.

[kronosapiens]

Currently the stake expenditure extension accepts a flag which optionally slashes reputation, as well as stake. We can copy that implementation over, and you can choose whether or not to expose that in the UI, or we can remove it entirely.