This is the first release of groups-ui, a user interface for interacting with the Cosmos SDK group module.
The terminology used here and throughout the user interface is the same terminology used in the Cosmos SDK group module. We recommend checking out Concepts to better understand group module terminology.
Features
Multi-Network Support
This application was designed to support multiple blockchain networks. The first version includes configurations for Regen Mainnet (regen-1) and Regen Redwood (regen-redwood-1). Users can switch between networks to create, manage, and interact with groups on each network using the same user interface. Additional networks can be supported by simply adding a configuration file to the source code.
Developers also have the option of forking and deploying the code with their own configuration. If this path is taken, we kindly ask that developers use this repository as the upstream version for new features, fixes, and improvements that would benefit this project and other forks and deployments. This option also enables developers to configure the application to support a single network rather than switching between networks.
Create And Manage Groups
The first version includes the ability to create a new group with a decision policy (either a threshold decision policy or a percentage decision policy), which includes adding an initial set of weighted members, supporting metadata for the group and the decision policy, and setting the admin of the group to either be the user creating the group or the decision policy created at the time of creating the group.
Once a group and decision policy is created, the admin will have the option of updating the group and decision policy. If the admin of the group and the decision policy is the decision policy account, group members can submit proposals to update the group and/or decision policy. The requirements for the proposal passing is based on the current decision policy.
Group Proposals
There are four types of proposals that can be submitted from the first version of the user interface. Each type includes one or more Cosmos SDK messages. Multiple messages from different types can also be included within a single proposal.
The first version of the user interface supports the following proposal types and messages:
- Text Proposal - A text proposal is a proposal that includes no messages. A user is simply submitting a group proposal that includes a title and description. This proposal can be used for a variety of purposes including signalling proposals and decision records.
- Send Proposal - A send proposal is a proposal that includes a message that will send tokens from the group (specifically from the decision policy account) to another account. Token options are available based on the balance of the decision policy account.
- Stake Proposal - A stake proposal is a proposal that includes a message to either delegate to a validator, redelegate from one validator to another, undelegate from a validator, or to claim staking rewards earned from existing delegations to a validator.
- Group Proposal - A group proposal is a proposal to update the group or the decision policy, including adding and removing members or updating member weights. This proposal type is only available if the decision policy account is set as the admin of the group.
In addition to submitting proposals, group members have the ability to vote on and execute proposals. To do so, the user must be a member of the group. The weight of each vote depends on the decision policy and the weight assigned to the member. A proposal can only be executed once the proposal has been accepted (i.e. the proposal meets the requirements of the decision policy). When a member executes a proposal, the account executing the proposal pays the transaction fee but the messages within the proposal are executed on behalf of the group (i.e. the decision policy account).
Historical Proposals
The Cosmos SDK group module is designed to prevent blockchain application state bloat. Group proposals are pruned from application state when a group proposal has been successfully executed or two weeks after the execution deadline (the time between the execution deadline and the proposal being pruned may vary depending on the network - two weeks is the default configuration but this value can be manually set within each blockchain application). Historical proposals are made available within the user interface using Regen Network's indexer. The first version of the user interface retrieves historical proposals from a graphql endpoint serving the proposals indexed by a new process added to the indexer.