Contact Information
-Name: John Smith
-Discord: John1254
-Email Address: johnsmith@gmail.com
ADO Summary - What is the goal of this ADO and how does it function?
The goal of the ADO is to have a multisig with a fixed set of addresses that can vote on proposals to execute some action on another ADO. (Usually this would be more descriptive but since a multisig is very common, a short description is enough here)
Does it need to work with another ADO or is it standalone? Also, does it implement any modules?
This ADO is standalone and does not implement any modules. (Examples of needing another ADO is an auction ADO that needs a CW721 ADO , or a CW20-Staking ADO that needs to work with a CW20 ADO)
Are you planning to build this ADO yourself, or by the Andromeda team
By the Andromeda Team.
Credits/Associations - Is this ADO based upon a previous project or ADO or in partnership with any other groups or developers? If so, please list here and provide a link if possible.
This ADO is based on the CW3-fixed-multisig contract from the cw-plus repo.
Can you provide any docs/articles/research that explains the main idea of the ADO and how/why it is used.
An article that explains the idea of a multisig smart contract
ADO Flow Breakdown - Please list and provide descriptions of each step in the ADO flow sequence (show us how to work with the ADO and associated workflow, visuals are great here):
Instantiation - What is defined when instantiating the ADO:
At instantiation, the following is specified:
A set of addresses that are allowed to sign/vote. Each is assigned a specific voting weight.
A threshold of votes that is needed for a proposal to pass
Note: Assigning a weight of 0 can be allowed which gives the address the right to start a proposal but not vote on it.
Execution - After instantiation, what is the process for working with the ADO:
When the ADO is instantiated, a registered address can submit a proposal with a description and the msgs that will be executed in case the proposal passes. The address that submitted the proposal will have their weighted vote automatically be considered a "yes".
Note: The proposer can set a duration for the proposal (should have a min and max allowed durations).
Once the proposal is up, the other addresses specified at instantiation can now vote. The vote can be either a "yes", "no", or "abstain". If the proposal gets enough votes to pass the set threshold, then it has passed and anyone can call an execute msg to execute the stored msgs that were specified in the proposal. If not, then the proposal can be closed and the msgs will not be executed.
Queries - What type of information will you need to include, search upon:
For this ADO we will need the following queries:
-A query to get proposal info (Voting status, duration, msgs, description etc..)
-A query to get the set of addresses allowed to vote along with their weights
Considerations/Concerns - What factors should be considered to mitigate risk of misuse, abuse, or other unintended scenarios, if any?
-Addresses should not be allowed to change their vote in order to stop people from changing last second.
-Having a way to simulate the msgs in a proposal before submitting it would prevent msgs that will result with an error. Having a message that will error would nullify the proposal and a new one must be made with correct messages instead.
Possible Next Iterations/Future Work - How can this ADO be further enhanced?
Another version of this ADO can also be considered being a flexible-multisig where multiple weights/thresholds can be assigned.
Any Dependencies or Third Party Integrations? (Ex. Will this ADO need to work with anything off chain, a different app, etc?):
Not applicable here. (An example of this would be an ADO that needs some specific oracle, chain, or protocol to work)
Contact Information -Name: John Smith -Discord: John1254 -Email Address: johnsmith@gmail.com
ADO Summary - What is the goal of this ADO and how does it function? The goal of the ADO is to have a multisig with a fixed set of addresses that can vote on proposals to execute some action on another ADO. (Usually this would be more descriptive but since a multisig is very common, a short description is enough here)
Does it need to work with another ADO or is it standalone? Also, does it implement any modules? This ADO is standalone and does not implement any modules. (Examples of needing another ADO is an auction ADO that needs a CW721 ADO , or a CW20-Staking ADO that needs to work with a CW20 ADO)
Are you planning to build this ADO yourself, or by the Andromeda team By the Andromeda Team.
Credits/Associations - Is this ADO based upon a previous project or ADO or in partnership with any other groups or developers? If so, please list here and provide a link if possible. This ADO is based on the CW3-fixed-multisig contract from the cw-plus repo.
Can you provide any docs/articles/research that explains the main idea of the ADO and how/why it is used. An article that explains the idea of a multisig smart contract
ADO Flow Breakdown - Please list and provide descriptions of each step in the ADO flow sequence (show us how to work with the ADO and associated workflow, visuals are great here):
Instantiation - What is defined when instantiating the ADO: At instantiation, the following is specified:
Execution - After instantiation, what is the process for working with the ADO: When the ADO is instantiated, a registered address can submit a proposal with a description and the msgs that will be executed in case the proposal passes. The address that submitted the proposal will have their weighted vote automatically be considered a "yes". Note: The proposer can set a duration for the proposal (should have a min and max allowed durations). Once the proposal is up, the other addresses specified at instantiation can now vote. The vote can be either a "yes", "no", or "abstain". If the proposal gets enough votes to pass the set threshold, then it has passed and anyone can call an execute msg to execute the stored msgs that were specified in the proposal. If not, then the proposal can be closed and the msgs will not be executed.
Queries - What type of information will you need to include, search upon: For this ADO we will need the following queries: -A query to get proposal info (Voting status, duration, msgs, description etc..) -A query to get the set of addresses allowed to vote along with their weights
Considerations/Concerns - What factors should be considered to mitigate risk of misuse, abuse, or other unintended scenarios, if any? -Addresses should not be allowed to change their vote in order to stop people from changing last second. -Having a way to simulate the msgs in a proposal before submitting it would prevent msgs that will result with an error. Having a message that will error would nullify the proposal and a new one must be made with correct messages instead.
Possible Next Iterations/Future Work - How can this ADO be further enhanced? Another version of this ADO can also be considered being a flexible-multisig where multiple weights/thresholds can be assigned.
Any Dependencies or Third Party Integrations? (Ex. Will this ADO need to work with anything off chain, a different app, etc?): Not applicable here. (An example of this would be an ADO that needs some specific oracle, chain, or protocol to work)