Picasso OpenGov
Governance mechanisms for Picasso are intended to ensure the growth and adaptation of the ecosystem in alignment with the wants and needs of the Picasso community. Therefore, all token holders are able to participate, with their votes being weighted by stake. Moreover, any alteration to Picasso must be approved by a referendum decided by PICA token holders.
Picasso’s Polkassembly will serve as a governance forum where open discussion about the future of Picasso can occur. Here, proposals can be refined based on community input.
The OpenGov structure for Picasso was implemented in two phases. Picasso has passed the first phase with phase 2 live in production.
Phase 1: Implement OpenGov with governance handled by two collectives: The Picasso Council and the Technical Committee. The purpose of this phase was to maintain the speed and efficiency demonstrated by the recent launches and connections on Picasso.
Phase 2: Now, the second phase of Picasso OpenGov is live, a new era of decentralisation, allowing PICA holders to actively participate in governance and a new structure of collectives.
Picasso’s OpenGov structure and design is an adapted version of Polkadot OpenGov.
Core Tenets
Core principles guiding participation in the Picasso OpenGov process are as follows:
- Supporting engagement of token holders who are influenced by and in turn would like to influence Picasso governance, even when their opinions and desires differ from that of the Composable team
- Prioritising the greater good of Picasso and its community over any individual interests
- Upholding transparency and openness with the public
- Acting morally and with a mind for consequences of action or inaction
- Standing firmly against any malicious language, behaviour, and actions
On-Chain Governance
Picasso’s hard governance involves on-chain mechanisms where the majority of tokens on Picasso determine key decisions. These decisions are made via token holders voting on proposed referenda, with individuals’ votes being weighted by staked token amount.
Definitions and components for OpenGov of Picasso are detailed below:
OpenGov Committees
The Technical Committee is a group of 5 core developers that are able to whitelist proposals. Its purpose is to provide technical review of urgent security issues and upgrades. The role of the Technical Committee includes, among others, ensuring the technical stability and critical safety measures of the parachain.
The Treasury Committee is an on-chain entity made up of 11 senior team members and supporters. Members of the Treasury committee consist of:
- Henry Love, Executive Director of Composable Foundation
- 0xBrainJar, Composable Founder & Research Director
- Blas Rodriguez Irizar, Composable Co-Founder & CTO
- Joe DeTommasso, Composable Head of Governance & Strategy
- Miguel Santefé, Composable Co-Founder & Head of Design
- Jafar Azam, Composable Devrel
- Jacob Gadikian, Notional Ventures Founder & CEO
- Jesse Abramowitz, Entropy Lead Software and Protocol Engineer
- Will Pankiewicz, Parity Master of Validators
- Tamara Frankel, D1 Ventures Founding Partner
- James Wo, Digital Finance Group (DFG) Founder & Chairman
The Treasury Committee also control Picasso’s multi-sig wallets holding the allocation for Liquidity Programs and Ecosystem incentives. Treasury spending can only be approved by this council; the funds from any of these wallets will only be transferred upon the approval of on-chain governance. For more details, refer to the PICA token transparency commitment statement.
The Relayer Committee involves accounts running the Hyperspace relayer.
Definitions
Origins
An origin is an authorization-based dispatch source for an operation. This determines the Track that a referendum is posted in.
Pre-Image Deposit
This is the amount of tokens that a proposer must bond to submit a pre-image. It is a base deposit per network plus a fee per byte of the proposed pre-image.
Pre-Image Hash
This is the hash of the proposal to be enacted. The first step to make a proposal is to submit a pre-image; the hash is its identifier. The proposer of the pre-image can be different than the user that proposes that pre-image as a formal proposal
Proposals
Proposals are an action or item (defined by the pre-image hash) proposed by a token holder and open for consideration/discussion by token holders.
Referendum
A referendum is a stake-based voting model. Each referendum is associated with an individual proposal for modifying Picasso in some way. This could include changes to code, parameters, or the governance of Picasso.
Tracks
This is a specific pipeline delineating the life cycle of a proposal. Tracks in Picasso OpenGov are Root, Whitelist Caller, General Admin, Referendum Canceller, and Referendum Killer:
| Track | Description | Example |
|---|---|---|
| Root | Highest Privileges | Runtime Upgrades |
| Whitelist Caller | Proposals handled by technical committee | Accelerated proposal |
| General Admin | On-chain changes | HRMP Channel Opening, XCM Fees, Staking parameters, Registrar |
| Referendum Canceller | Canceling proposal | Incorrect referendum |
| Referendum Killer | Canceling proposal + slashing deposits | Malicious referendum |
Voting
Token holders can approve or reject proposals.
A vote’s weight is defined by the following:
- The number of tokens a user commits to a vote
- The lock period of the vote; in Picasso OpenGov, users can voluntarily lock tokens to increase their voting power, with longer lock periods associated with a conviction multiplier on vote weight:
| Lock Period After Enactment | Conviction Multiplier | Lock Time |
|---|---|---|
| 0 | 0.1x | None |
| 1 | 1x | 28 days |
| 2 | 2x | 56 days |
| 4 | 3x | 112 days |
| 8 | 4x | 224 days |
| 16 | 5x | 448 days |
| 32 | 6x | 896 days |
Vote Delegation
Voters can delegate voting power (including conviction multiplier) to other token holders (“delegates”). This feature exists to allow tokens to be delegated to those who may be more knowledgeable about the Picasso network and thus able to make more informed decisions on specific referenda.
Multirole Delegation
Voting power can be delegated based on tracks, e.g. token holders can specify different delegates for each track.
Approval
This is the minimum number of votes for passing a referendum, as a percentage of total conviction-weighted votes needed to approve the referendum.
Support
This is the minimum number of votes for passing a referendum (NOT taking into consideration conviction-weighted votes) needed to approve the referendum.
Lead-In Period
This is the initial period of discussion and voting on a proposal. During this period, proposals are undecided until they pass the criteria for a Track, which include:
- The prepare period, or the minimum time a referendum needs to wait before it can progress to the next phase after submission
- Capacity, or the limit for a number of referenda on a given track that can be decided at once
- Decision deposit, or the minimum deposit amount needed for a referendum to progress to the decision phase after the lead-in period ends; this deposit is larger than the submission deposit in order to limit spam proposals/referenda
Details on the lead-in period (specifically, the prepare period) for each track are found in the OpenGov Parameters section of this documentation.
Decision Period
During this period, token holders continue to vote on the referendum. If a referendum does not pass by the end of the period, it will be rejected, and the Decision Deposit will be refunded. Details on the decision period for each track are found in the OpenGov Parameters section of this documentation.
Confirm Period
This is a period of time within the decision period where the referendum needs to have maintained enough Approval and Support to be approved and move to the enactment period.
Details on the confirm period for each track are found in the OpenGov Parameters section of this documentation.
Enactment Period
This is a specified time, defined at the time the proposal was created, that an approved referendum waits before it can be dispatched. There is a minimum amount of time for each Track. Details on the enactment period for each track are found in the OpenGov Parameters section of this documentation.
OpenGov Parameters
Governance parameters (for each referenda track) are as follows:
| Track | Track ID | Concurrent Proposals | Decision Deposit |
|---|---|---|---|
| Root | 0 | 5 | 5,000,000 PICA |
| Whitelist Caller | 1 | 25 | 500,000 PICA |
| General Admin | 2 | 10 | 1,000,000 PICA |
| Referendum Canceller | 3 | 10 | 1,000,000 PICA |
| Referendum Killer | 4 | 25 | 1,000,000 PICA |
Period Parameters by Track
| Track | Prepare Period | Decision Period | Confirm Period | Min. enactments |
|---|---|---|---|---|
| Root | 1 day 2 Hours (600 Blocks) | 10 Days (72000 Blocks) | 1 Day (7200 Blocks) | 1 day |
| Whitelist Caller | 10 mins (50 Blocks) | 10 Days (72000 Blocks) | 30 mins (150 Blocks) | 10 mins |
| General Admin | 1 hour (300 blocks) | 10 Days (72000 Blocks) | 1 Day (7200 Blocks) | 1 day |
| Referendum Canceller | 1 hour 1 Day (7200 Blocks) | 10 Days (72000 Blocks) | 3 Hours (3600 Blocks) | 10 mins |
| Referendum Killer | 1 hour 1 Day (7200 Blocks) | 10 Days (72000 Blocks) | 3 Hours (3600 Blocks) | 10 mins |
Approval Curves
With X % of support, Referenda can pass after Y duration (time periods in the table) since the beginning of referenda depending on whethere the approval rate is above the approval curve.
Approval curve for the Whitelist Track
Approval curve for the Root Track
Proposal Roadmap
- A proposal author should submit their idea to Picasso’s Polkassembly governance forum, where they should be open to community feedback for at least five days before moving forward
- Taking into account feedback, the proposal author can submit their proposal on-chain
- The proposer must first submit the preimage (if you need assistance with creating the preimage or would like secondary approval, reach out to our team on Discord)
- Note: your preimage deposit will be returned once via unnoting after the proposal is submitted
- The proposer then can submit the Referendum, and place the decision deposit (which covers the on-chain storage cost of the proposal)
- Thus veins the lead-in period, where the community can begin voting
- The proposal will then move to the decision period when the following are met:
- The referenda waits the duration of the prepare period (ensuring enough time for discussion)
- There is capacity in the chosen track
- A decision deposit has been submitted and meets the minimum requirements of the track
- During the decision period, voting continues and the referendum has a set amount of days to reach approval.
- If the Referendum is rejected, the decision deposit will be returned
- If the Referendum is approved, it enters the confirm period where it must remain approved for the duration of this period.
- If the referendum fails to meet these requirements at any time, it moves back to the decide period; if it again meets these requirements, it moves back to the confirm period and the decide period is delayed until the end of the confirm period
- If the referendum receives enough approval and support throughout the confirm period, it will be approved and move to the enactment period
- Once the enactment period elapses, the referendum will be executed
Proposal Cancellations
If a proposal in the voting stage is found to have an issue, it may be necessary to prevent its approval. This could be due to malicious activity or technical issues that void the proposal.
Cancellations must be voted on by the network. Cancellation proposals are expedited, as they must be decided before the enactment of the proposal they seek to cancel. However, the same process as standard referenda applies.
Moreover, a cancellation Origin called the Emergency Canceller exists for use against any referendum with an unanticipated issue. The Emergency Canceller Origin and the Root Origin can cancel referenda. Regardless of the Origin, if a proposal is cancelled, it is rejected and the decision deposit is refunded.
The Kill Origin called Emergency Killer exists for use against malicious referenda. The Emergency Killer Origin and the Root Origin have the ability to kill referenda. The difference between killing and cancelling a referenda is that in the case of a kill, not only is the proposal cancelled, but also the Decision Deposit is slashed, meaning the deposit amount is burned regardless of the Origin.